Checked vs. Unchecked exception

[Reto Bachmann-Gmür <re...@apache.org>]

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

Re: Checked vs. Unchecked exception

[Reto Bachmann-Gmür <re...@apache.org>]

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 <christ.fabian@googlemail.com
> 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 <re...@apache.org>:
> > 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
>

Re: Checked vs. Unchecked exception

[Fabian Christ <ch...@googlemail.com>]

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 <re...@apache.org>:
> 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