0

I read a lot of stuff about why you should not catch "Throwable". That's not what I'm asking, since this is very obvious to me. But what would actually be cases, where it would make sense to do that? I see it here and there and to me, code like that is completely broken.

All I can think of could maybe be a watchdog, that watches an application and restarts it, if it crashes. Not sure if that makes sense, but an app should never watch for Exceptions including Errors within it's own code base, right?

codepleb
  • 10,086
  • 14
  • 69
  • 111
  • if you can handle it at the spot, without breaking down the entire flow, why not? it all depends on the requirements. – Stultuske Aug 23 '18 at 07:56
  • 1
    @Stultuske Sure, but you obviously don't want to catch something like "OutOfMemoryError" and put yourself higher than the JVM, because the application won't be healthy afterwards, if you don't let it die. At least, that's how I imagine it. Maybe you can use it for logging purposes, but if an error happens, my understanding is, that an app has to crash. – codepleb Aug 23 '18 at 07:58
  • @ernest_k that is the exact opposite of this question – OhleC Aug 23 '18 at 07:59
  • Related: https://stackoverflow.com/q/6083248/6699433 – klutt Aug 23 '18 at 08:03
  • There are situations where catching Error and continue is appropriate. Ex: In a servlet, if you enconter an OutOfMemoryError because a specific request happen to eat all the memory, you can try to continue since the objects will be GC after the request is handled. – Prakhar Nigam Aug 23 '18 at 08:04
  • @codepleb catching fatal VM errors like 'OutOfMemoryError' is nonsense, so you should never generally catch Throwable, which includes Errors. But if you deal with loading native libs, maybe you want to handle errors like 'UnsatisfiedLinkedError'. Here your app does not have to crash mandatory. – bucky Aug 23 '18 at 08:05
  • @codepleb you can't just "handle" an OutOfMemoryError on the spot without the flow being impacted. Just because Throwable should never be manually thrown (instead of a clear and custom BusinessException) doesn't mean that people never do it. – Stultuske Aug 23 '18 at 08:07
  • One use case is to catch `Throwable` at the very top level of your application to log information about the state of your app when that statement is reached and help fix potential bugs. But that can also be achieved with an `UncaughtExceptionHandler`. – assylias Aug 23 '18 at 08:07

3 Answers3

0

One good reason is if you want the application to write information about the error to a log file or something like that.

klutt
  • 30,332
  • 17
  • 55
  • 95
0

There are two schools of thought when it comes to exception handling. The first states that it's reckless to catch exceptions for they demonstrate issues living in the code that ought to be fixed. The alternative is to use exceptions when you expect them or for debugging, I would offer any communication between two devices as an example since omitting catch blocks in these applications can crash a program over uncontrollable but foreseeable connectivity issues. I think it's reasonable to suggest that catch blocks have their place in circumstances that can be understood and planned for, ensuring that only foreseeable exceptions are caught and those not accounted for are left to crash the program and let you know of something that needs fixing.

Sonic7662
  • 66
  • 6
0

Checkout Hystrix for example - if you get an error due to HTTP request you can then retry and fallback to it - that's better than just throwing exepction due to HTTP request error.

tryingHard
  • 1,794
  • 4
  • 35
  • 74
  • For these cases it sounds like a more precise catch would be way more appropriate than a generic throwable. – klutt Aug 23 '18 at 09:12