-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Standardize naming of Exceptions and Errors. #5566
base: master
Are you sure you want to change the base?
Conversation
|
Maybe we should call everything Exception? I never understood why Ruby uses Error, it's pretty confusing. |
IMO as long as a convention is setup it should be fine. I am leaning more towards what @asterite has suggested and just call everything |
Hello! Thank you for taking the time to go over all exceptions/errors and attempt to unify them! Even more considering is your first contribution! For reference, here are a few references when Error/Exception has been adjusted: I remember there was another rename sprint, but I cannot remember the conversation/links to it. Apologies. Hope this helps. Cheers. |
@asterite The argument that an "exception" is just a technical concept encapsulating stack unwinding. Errors are a concrete usage of how exceptions are used. Not all errors are exceptions (returning nil), and not all exceptions are errors (you can use exceptions to signal things, although it's not really good practice). I'm not sure I buy whether this argument is worth the confusion it causes though. |
Two random thoughts on the subject of error design, from ruby-land: 1.
So with this in mind... I can see utility in making a distinction between errors that can be viewed as within a programmer's deterministic control, versus those that can be blamed on the unintended runtime side effects of external systems. However from a language design perspective... that Thoughtbot even needed to write a "PSA" to explain to experienced programmers the huge practical differences between 2. Don't write errors that assume understanding of Ruby's internal classes One Ruby error code that I constantly see trip up new students in coding bootcamps is Ruby's Don't assume programmers understand classes well. Especially Ruby's internal classes. I know Crystal doesn't have nil, but there are still lessons to be learned from this example as is relates to how method calls can fail. E.g. don't tell the user just about where the method call failed: make them aware about how that variable got assigned as well too. |
Is this still relevant (If I fix the merge conflicts)? Otherwise I'll close it. |
Closes #5559.
Standardizes naming of
Exception
s andError
s in Crystal. The convention is to name everythingFooError
and make the base class for all the errorsException
. The classesJSON::ParseException
,YAML::ParseException
,INI::ParseException
andInvalidBigDecimalException
did not follow this convention. I have renamed all of them (ensuring that nothing broke).I'm not sure what
OptionsParser::Exception
does so I didn't rename it.References: