3 ms·
>ignore unexpected exceptions Isn't it the way it already is in practice, not something specific to Erlang? If an exception is unexpected, usually there won't
by kgeist 4y ago
>ignore unexpected exceptions
Isn't it the way it already is in practice, not something specific to Erlang? If an exception is unexpected, usually there won't be an exception handler for it, otherwise a developer pretty much expected it. Developers are generally lazy so in my practice the default is usually to let it fail, and there's usually going to be an exception handler that does something other than logging and quitting only if there's a serious reason to do so.
Maybe a more useful distinction could rather be "business logic errors" vs. everything else ("infrastructure errors", "programming errors" and "input validation errors"). Business logic should clearly define what should be done when an error happens, to avoid inconsistent state. But infrastructure-level errors or programming errors, you can't do much about them, other than log and/or retry.
- gabeio 4y ago> If an exception is unexpected, usually there won't be an exception handler for it That honestly depends on how the language and program are written, python is a great and horrible example of where you can handle any exception even ones that were just created by the program: try: crash_hard_here() except: # by default (and unfortunately) will catch *everything* pass # and this is one of the worst offenders inside an except, to just outright ignore the exception and continue as if nothing happened and to not even log it. I can not tell you the amount of production code where I've seen catch all exceptions, and they are the lazy way to know something will not "crash" even though much worse things can happen now.
- blub 4y agoThis catch and ignore seems to be straight out of the (sadly not real) Visual Basic design patterns book :-)
- blub 4y agoIn C++ for example there’s an exception hierarchy and several classes of errors similar to what you enumerated, so the handler might catch a specific exception as a more generic one. There’s also … which catches all exceptions. This is fine, as one has the choice of exposing error details to outside code or not.