OptionsParser::Exception is just a base class for OptionParser::InvalidOption and OptionParser::MissingOption. IMO they should all be named Error.

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 Exception, since the base class is called Exception. This way it makes things a lot more idiomatic.

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:

• Rename Channel related classes #1477
• Rename a couple exceptions #1480
• 38d3662

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. Exception vs StandardError causes lots of confusion
In Rails/Ruby-land there is a strong convention that one should always rescue from StandardError, rather than Exception. However, it's not well known in my experience. The difference being:

Exceptions that aren’t StandardErrors are reserved for things like Interrupt when we hit Ctrl-C, and NoMemoryError.
Exceptions that are StandardErrors are what a normal Ruby program are supposed to use.

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 Exception and StandardError (due to an epidemic of apps rescueing from Exception not knowing its implications) -- could be seen as evidence of failure in Ruby's language design: As yet another conceptual "quirk" someone must learn before they can achieve systems mastery, or write a program that won't error out in completely unexpected ways.

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 undefined method 'foo' for nil:NilClass. It screams into the face of the learner that the problem has to do with the method's definition being called, rather than the particular class it's being called upon.

Don't assume programmers understand classes well. Especially Ruby's internal classes. undefined method 'foo' for nil:NilClass is the kind of error wording that only makes sense to a language designer who's deep in the thought process of strictly mapping classes to methods. In reality, a better design would be one where the error can infer or guide a user with its language into what aspect of this mismatch is most likely the problem. E.g. Is the problem likely with your method's definition, or is it almost certainly how ridiculous it appears for you to be calling on a Ruby internal class like Nil this kind of method definition? The heuristic being: Don't assume the programmer understands classes well.

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.