Changes between Version 6 and Version 7 of GeoNetworkException

Timestamp:

Dec 2, 2008, 2:40:31 AM (15 years ago)

Author:

heikki

Comment:

--

GeoNetworkException

@@ -18 +18 @@
 For now only one exception is implemented (org.geonetwork.domain.ebxml.exception.GeoNetworkException). We can add and diversify more of course. 
 
-Heikki: -1. When was option 1 chosen and by whom ?? In my opinion throwing !RuntimeExceptions as a default strategy for exception handling does not make any sense. Also I do not think that try-catch blocks 'dirty' the code. Throwing !RuntimeException is a bit like avoiding strong typing by using ony java.lang.Object as parameter type; or like the current practice in GeoNetwork not to model an object domain, but do everything with JDOM Elements. Also what will we do if a !RuntimeException occurs: let the JVM exit?? I think not; this means we'll catch them somewhere in any case.
+Heikki: -1. When was option 1 chosen and by whom ?? In my opinion throwing !RuntimeExceptions as a default strategy for exception handling does not make any sense. Also I do not think that try-catch blocks 'dirty' the code. Throwing !RuntimeException is a bit like avoiding strong typing by using ony java.lang.Object as parameter type; or like the current practice in GeoNetwork not to model an object domain, but do everything with JDOM Elements. Also what will we do if a !RuntimeException occurs: let the JVM exit?? I think not; this means we'll catch them somewhere in any case. For an explanation about exception handling see for instance [http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html Unchecked Exceptions — The Controversy]:
+  Generally speaking, do not throw a !RuntimeException or create a subclass of !RuntimeException simply because you don't want to be bothered with specifying the exceptions your methods can throw. 
 
 Erik: +1. Since I like the minimalistic approach I prefer 1. Another advantage is that you have always the choice to catch the exception. In this project does it mean that the exception will be catched in the service layer. In all other layers you don't see boilerplate code, only code which makes sense.