One or more general exception are needed to organise exception handling in the application.

Option 1: GeoNetworkException extends java.lang.RuntimeException This is a non checked exception.

• Advantage: less boilerplate code
• Disadvantages: requires well tested code

Option 2: GeoNetworkException extends java.lang.Exception This is a checked exception. Users of api's who can throw this exception need code to catch the exception.

• Advantage: it is explicit which exceptions can be thrown
• Disadvantages: code gets dirty with try catches

Chosen option 1 (disputed): The application is well unit tested. It is important that the code remains clean.

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.

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.