I dislike exceptions for the same reason, because it’s often not clear if the error will come through an indirect channel (the exception), or in the return value. It’s better in languages that express that in their type system.

And unless you catch the common ancestor for all exceptions, it’s difficult to know what you need to look out for. This is especially true in dynamic languages like Ruby.

To my mind, exceptions enter a language when the language lacks the semantics to expose them in the return value, where true/false/null/errno is too primitive for larger systems.

Option, Result, and Either are great alternatives that allow you to propagate problems to deal with them at a higher level, with explicit acknowledgment that an error might occur.

Exceptions can be ignored and caught in random places with little to no context, so long as they’re further up the stack. Or you just get stuff like:

    try {
      Application->runTheWholeThing();
    } catch (e) {
      print “something went wrong”;
    }