I saw this tweet but I'm still lost when it is a g...

# announcements

[Hexa]

I saw this tweet but I'm still lost when it is a good idea to catch Throwable as there is not a very clear example provided in the tweet or I got lost reading the conversation https://twitter.com/relizarov/status/1299248297849303040?s=19

[thana]

generally catching exceptions is advised only when you can handle them.
Trying to catch ALL Exceptions usually is only necessary when logging them (or make sure you don't leak them into an http api for example).
If this is your intent you should catch Throwable not Exception

[Hexa]

So in Kotlin if I am going to catch Exception then I might as well catch Throwable, still would be great to see more clear examples/explanation

[Hexa]

Java says not to catch error but this isn't Java I know

[nfrankel]

you shouldn’t catch Throwable
out-of-memory error is a throwable
what are you going to do?
nothing
you just cannot recover at this point
just let it go

[elizarov]

You should catch all throwables (including OOMs) for the purpose of logging/reporting and usually you can recover from all of them. Thank me later when it saves you a lot of time debugging your code.

[nfrankel]

i disagree
if you have no more memory
then how would allocate objects to log? 🤔

[elizarov]

It is often thrown on a failure to allocate some very big object (typically array inside some arraylist) while there’s still plenty of memory to log stuff.

[Nir]

I'm curious, is it some kind of JVM magic that generates the OOM? Otherwise, it's worth keeping in mind that on a typically-setup linux box, you will never receive OOM, due to overcommit

[danny]

I’d use uncaught exception handlers: avoids the messiness of accidentally not rethrowing ThreadDeath and means your code can focus on the errors you care about. IIRC the default handler will print the stacktrace to stderr