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.