0

There is a static exception path on class Spark, but it only takes something that extends from Exception. If an error occurs that is a Throwable, but does not extend Exception, there appears to be no way to catch it in the Spark API to log or handle it before a 500 is returned to client.

Example of a common type of Throwable that can't be mapped to Spark.exception: java.lang.ExceptionInInitializerError

Any way to get hold of these in Spark before they disappear out to client, without wrapping the functions of every route in a try/catch(Throwable)?

Pablo Matias Gomez
  • 6,614
  • 7
  • 38
  • 72
Jim Weaver
  • 983
  • 5
  • 15

1 Answers1

2

You can't catch Throwable errors in Spark.

The thing is that Throwable includes Error Error is programmatically unrecoverable and therefore is usually not to be caught. On the other hand Exception is programmatically recoverable, and therefore something that you may want to catch.

I recommend you reading

You should ask yourself why are you trying to catch Throwable's and maybe modify that part (if that code of yours).

Community
  • 1
  • 1
Pablo Matias Gomez
  • 6,614
  • 7
  • 38
  • 72
  • Most API frameworks, like Jersey for example, are going to give you a catch-all hookpoint for Throwable, because regardless of whether it is recoverable or unrecoverable, an error is about to flow out to your client, and you want to at least log it before it does. As Spark stands now, if a Java Error subclass is thrown, there is no way without explicit try / catch blocks in every endpoint method to log them before the 500 goes out to client. Your answer is correct I think, though - and same conclusion I came to - they just don't have a way to do it. – Jim Weaver May 12 '17 at 00:58
  • As an aside, if you are willing to use aspects on a project, that could be done to be sure to log any throwable escaping a spark class. – Jim Weaver May 12 '17 at 01:00
  • Returning something to the client may be also imposible. In case an `Error` happens, it can be, for example, that you have no more memory. There is no guarantee to do things at that point. Although trying to log something could be good.. – Pablo Matias Gomez May 12 '17 at 02:26