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 2 (disputed)''': 
In the ESA chat on December 1st 2008, option 2 was preferred by Heikki & Jose. Erik does not agree but accepts his is a minority position on this issue.

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. 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. The application is well unit tested. It is important that the code remains clean. 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.