Tasos Martidis

If you mean Effective Java by Joshua Bloch I have read it (2nd edition, did get my hands on 3rd yet) and I it shaped my opinion on how to handle exceptions as well I believe.

Thanks for your comment. Java's Error class and the Error class of the example would never be confused/mixed. Some differences:

- The package name of the class. java.lang.Error vs whatever our package is

- lang.Error is classloaded by the bootstrap classloader while our "custom" from the application classloader

- The Error class in the example is not Throwable, just a class containing information

But in any case, you can name the class that holds the information about the "failure event" in whatever name you prefer, thats not really the point I was trying to make.

But still I appreciate you taking the time to read and give feedback

Thanks for the feedback and good point!

Translating the exceptions between levels to the appropriate abstraction, I consider a must. After that, there are cases where you could need context to handle the exception accordingly.

Let's consider that our application calls another component via HTTP and an exception occurs in the call. Also, we would handle a timeout by retrying but a not authorized error by giving up. I would pass the exception as a ServiceException to higher level, and then I would:

- Either, create hierarchy by creating ServiceTimeoutException and UnauthorizedException which extend ServiceException

- Or, pass the exception in the constructor. But never exceptions that could give sensitive information

I heavily prefer the first option, but I wanted to mention both. In general I expect that my thoughts on this have contradictions and paradoxes, and the approach should be decided per case and context.

Again, I really appreciate the feedback!