I saw this tweet but I'm still lost when it is a g...
# announcements
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
👍🏾 1
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
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
Java says not to catch error but this isn't Java I know
you shouldn’t catch
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
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.
❤️ 4
i disagree if you have no more memory then how would allocate objects to log? 🤔
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.
✔️ 6
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
I’d use uncaught exception handlers: avoids the messiness of accidentally not rethrowing
and means your code can focus on the errors you care about. IIRC the default handler will print the stacktrace to stderr