Hi - By default the exceptions in we define for our API should inherited from RuntimeException - If an exception is not a RutimeException the API doc should specify what the client is expected to do with it, and this should be different from what the client is expected to do with RuntimeExceptions
I created STANBOL-949 for these changes and changed a first exception (EntityhubException). Cheers, Reto On Tue, Feb 12, 2013 at 2:50 PM, Fabian Christ <[email protected] > wrote: > Hi, > > sounds reasonable even though I have to say that I do not have that > much experience how to do it right. > > Best, > - Fabian > > 2013/2/9 Reto Bachmann-Gmür <[email protected]>: > > Hello, > > > > I've just experienced a runtime incompatibility after compiling > > against the released version of entityhub: > > > > Uncompilable source code - unreported exception > > org.apache.stanbol.entityhub.servicesapi.EntityhubException; must be > > caught or declared to be thrown > > > > I think in general we should use unchecked exceptions (i.e. exceptions > > inheriting from RuntimeException) and limit the use of checked > > exception to the rare cases when the invoking code is expected to deal > > with the exception in a particular way. When the code is likely to > > just log error or inform the user and fail, then the exception should > > not be checked. So a NoMoreAnnotationsException may be checked > > (especially id there is no hasMoreAnnotations method and the client is > > expected to invoke the method till the Exception occurred) but an > > EntityHubException which simply indicated that something went wrong > > should not be checked as there is no strong argument why clients > > should handle this exception differently from an arbitrary Exception. > > > > Cheers, > > Reto > > > > -- > Fabian > http://twitter.com/fctwitt >
