Sadly, `Error` includes more than just fatal JVM t...

# announcements

[Matt]

Sadly, Error includes more than just fatal JVM throwables (e.g. AssertionError), which is why Scala has NonFatal

[Shawn]

is there anything broader than AssertionError included under Error? I feel like that’s fine to consider non-catchable since it really only ought to be seen when a test fails

[Matt]

Not uncommon for people to use assertions in defensive production code

[karelpeeters]

What? If an assertionerror happens your program has a fundamental bug, same for indexerror.

[Matt]

It may have fundamental bug, but that's a very different thing from a fatal JVM throwable. You often want to catch the former, very rarely the latter

[karelpeeters]

You want to catch assertion errors? There's no recovering from them, your program is broken.

[Matt]

Not at all, this situation is not at all uncommon. Two examples from many:
1) You're writing an app with a plugin architecture, and want to uniformly handle exceptions thrown from an extension point
2) You're writing a microservice, and want to handle all unexpected application exceptions with a standardised response body.
In both cases, you legitimately want to handle exceptions that are a result of bugs and otherwise unrecoverable errors, but not fatal JVM throwables

[karelpeeters]

And for those couple of special cases listing the couple of exceptions you want to check isn't that bad.

[Matt]

Yes, I'm aware that I can implement this myself, but it would certainly be better to rely on a piece of library code should it exist, which is why I'm asking.

[Matt]

Further, Scala uses a custom ControlException to implement certain language features, and that should not be caught by user code, in addition to the standard library fatal throwables. Kotlin may or may not have a similar exception, but I simply don't know.