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.