Talk:10 best practices with Exceptions

Thx for this article, very interesting !

Jmix from http://lexique-du-net.com/blog/

--193.54.225.89 12:04, 14 January 2009 (UTC)

Nice article!

In layered architecture such as web -> service -> repository(dao) these two principles i.e Encapsulation and "Throw early catch late" some how seem to conflict. It makes sense to for each layer to encapsulate exception and throw it further. For example service layer will catch repository specific exceptions and encapsulate these with service exception and throw it to web layer. However this defeats the principle of "CATCH LATE" and some times just becomes an over head. Any thoughts/work arounds?

Thanks, Mohit Manrai

--193.130.13.233 12:06, 14 January 2009 (UTC)

Thank you Mohit.

Thanks for your comment. I think when you are doing encapsulation you are not really catching the exception but just forwarding it to the next level, and leaving a trace of where the exception has passed by. The real catch happens when you really do something with it and don't forward the exception any more.

I don't think nesting all these exceptions is an overhead, consider the case where you are using a DAO interface which is implementation independent and you can't sayif the DAO will access a local DB, a remote DB or even a plain XML file.

From the point of view of the client of the DAO it doesn't make sense to be catching several exceptions like UnableToConnectException, FileNotFoundException or SQLExceptions. Catching all these would be the real overhead.

Your DAO may be able to deal with these exceptions and catch them straight there. Or it may be not able to solve them and just pop them up encapsulated for example into a DAOException. The DAOException would climb up the levels until it gets to a method able to deal with it (throw early catch late). Thanks to encapsulation this method would easily get the list of Exceptions nested and thus know where the exception has passed by and have great detail on what went wrong. In complex situations this may result useful because he may get the similar exceptions from different contexts and be able to find the best solution.

For example if a method catches a ShapeException thrown by some method called in its body, it may be interesting to know what shape was causing the problem if it was a triangle or a square. Plus it may be useful to know if it was in a box or in a notebook if the triangle was in a box or in a notebook. it may be:

• ShapeException->BoxException->TriangleException or a
• ShapeException->NotebookException->TriangleException

using encapsulation in this way you can have all the information you need about the exception directly inside the exception. This doesn't add too much complexity, and in the event your program will grow in dimensions, you have a very scalable exception handling mechanism in place. Hope this answers your question.

--DonGiulio 12:20, 14 January 2009 (UTC)

Mohit Manrai : Encapsulating exceptions just because we want to encapsulat it, is not a good practice, and leads to overhead you had mentioned. We want to encapsulate exceptions, because we want to hide the details of inner implemenation from the outside:

   - we do not want to make compile-time dependences to exceptions declared in some inner libraries/layers we depend
   - we want to leave us freedom of change the details of inner implemantation, and used libraries/layers. Declaring exceptions from inner libraries in interface methods would stick us to those libraries.

Encapsulate, if one of the above criteria is meet.

"catch late" does not mean literally 'catch' in this sentence. It is more like 'serve' - do some concrete response to the unexpected situaltion reported by the exception. This does not mean 'catch, encapsulate and throw'.

By the way, who knows why the above example of "use finally" is an antipattern? Because, in this wrongly coded example, any exception thrown by new FileWriter(fileName) would be hidden by NullPointerException throw from line 'output.close()'. This is not the worst case, because we used e.printStackTrace() before. At least we will have any log in the console. More danger would be, when we would use encapsulation instead of e.printStackTrace() - than, original exception would be lost.

Best Regards Marcin Sarniak Isolution Java Blog

--89.76.110.14 13:26, 14 January 2009 (UTC)

Marcin: how would you solve that antipattern?

thanks & regards, --DonGiulio 13:51, 14 January 2009 (UTC)

First two thoughts:

If (output != null) {
   output.close()
}

or

catch (Throwable th) in finally <-- in finally designed to clean resources, with none specific business logic, it is acceptable, because safer: does not hide the primary exception.

--89.76.110.14 14:03, 14 January 2009 (UTC)

Hello, In my first proposed sollution, I was thinking of:

try {

   if (output != null) {
      output.close();
   }

} catch (IOException e) {

  e.printStackTrace();

}

BR, Marcin Sarniak http://blog.isolution.pl

--89.76.110.14 16:11, 14 January 2009 (UTC)

Thank you DonGiulio & Marcin for your response

Mohit Manrai

--193.130.13.233 16:50, 15 January 2009 (UTC)