Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Differentiate between exception and error #8

Open
jwoertink opened this issue Dec 27, 2021 · 1 comment
Open

Differentiate between exception and error #8

jwoertink opened this issue Dec 27, 2021 · 1 comment

Comments

@jwoertink
Copy link
Member

Ref: luckyframework/lucky#1314
Ref: luckyframework/avram#773
Ref: luckyframework/lucky#1463

The idea here is that when you (the developer) are using Lucky, and you use the tools incorrectly, you should be given an error message. When you use the tools correctly, but it just doesn't work, then you should be given an exception.

I'm not totally sold on any single implementation for this, yet; however, my first thought is the distinction between these:

# Error
puts "You for got to add something".colorize.red
exit(1)

# Exception
raise "Unable to do that thing"

We sort of use a mix of these now, and it's pretty inconsistent.

If valid, print good, else print bad.
https://github.com/luckyframework/lucky/blob/a12ddfb1b9b0edfc6594e0555140f96987fd25ab/tasks/gen/action/action_generator.cr#L20-L25

do thing, rescue and print bad if it fails
https://github.com/luckyframework/lucky/blob/a12ddfb1b9b0edfc6594e0555140f96987fd25ab/tasks/gen/resource/browser.cr#L34-L40

if error print bad, else print good
https://github.com/luckyframework/lucky/blob/a12ddfb1b9b0edfc6594e0555140f96987fd25ab/tasks/gen/page.cr#L21-L26

run through the code and constantly check progress. raise exception at any point
https://github.com/luckyframework/lucky/blob/a12ddfb1b9b0edfc6594e0555140f96987fd25ab/tasks/gen/resource/browser.cr#L90-L101

@jwoertink
Copy link
Member Author

This just came up again

Ref

Currently if you call a positional_arg, and the value is nil, you'll get this generic message like is required, but no value was passed. which is fine... not great, but ok... But in Lucky, we had some custom error message that would print out in a nice way. Then I converted a task from using ARGV.first to the positional_arg which turned the nice error in to an exception. In order to revert back to the nice error, I had to use some rescue magic. It would be better if we just created this separation between what's considered an exception and what's just a UI error.

raise "{{ arg_name.id }} is required, but no value was passed."

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant