https://kotlinlang.org logo
Title
m

Matt

08/20/2018, 3:07 PM
Sadly,
Error
includes more than just fatal JVM throwables (e.g.
AssertionError
), which is why Scala has
NonFatal
s

Shawn

08/20/2018, 3:09 PM
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
m

Matt

08/20/2018, 3:11 PM
Not uncommon for people to use assertions in defensive production code
k

karelpeeters

08/20/2018, 3:36 PM
What? If an assertionerror happens your program has a fundamental bug, same for indexerror.
m

Matt

08/20/2018, 3:56 PM
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
k

karelpeeters

08/20/2018, 4:06 PM
You want to catch assertion errors? There's no recovering from them, your program is broken.
m

Matt

08/20/2018, 4:33 PM
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
k

karelpeeters

08/20/2018, 9:41 PM
And for those couple of special cases listing the couple of exceptions you want to check isn't that bad.
m

Matt

08/21/2018, 6:49 AM
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.
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.