[teeray]

Exceptions are also problematic in Ruby. It quickly becomes impossible to look at any method and answer the question "what exceptions can this raise?"

Ruby has rich exception handling mechanisms, but everyone just uses "rescue" without any arguments (or worse, "rescue Exception") because of the elusiveness of the answers to that question.

[FanaHOVA]

Most of these problems arise from bad engineering cultures though, not the language itself.

[teeray]

Discipline can only get you so far. If you call a method coming from a third-party gem, you will still have no idea what exceptions could be raised by it no matter how well you've handled exceptions sourced from your own code.

[nix0n]

That's true, but it's also possible to prevent these problems within a language, as Java does: https://docs.oracle.com/javase/tutorial/essential/exceptions...

(Not trying to start Java v Ruby here, just looking at how exceptions work)

[FanaHOVA]

It definitely is, but what happens when you'd like to use the other behavior? There's definitely certain occasions in which you want to use the not-best way to do thing. Leaving the choice to the programmer rather than removing the feature from the language is the way to go imo.

[vinceguidry]

Yes, you can absolutely make Exceptions a first-class domain concept, I've been doing this in a worker instrumentation that I've been doing. I have a custom error class that inherits from StandardError, and the exception handling code handles these custom errors differently than other errors.

This way knowledge can be slowly wrapped around the failure modes as they get seen.