exceptions thrown by methods in AnalysisComponent

[Marshall Schor <ms...@schor.com>]

The initialize method declares it throws ResourceInitializationException.

The reconfigure method declares it throws this plus 
ResourceConfigurationException.

Should the initialize method have the same "throws" declaration as the 
reconfigure method?

-Marshall

Re: exceptions thrown by methods in AnalysisComponent

[Adam Lally <al...@alum.rpi.edu>]

On 11/23/06, Marshall Schor <ms...@schor.com> wrote:
> The initialize method declares it throws ResourceInitializationException.
>
> The reconfigure method declares it throws this plus
> ResourceConfigurationException.
>
> Should the initialize method have the same "throws" declaration as the
> reconfigure method?
>
> -Marshall

This is mainly historical, and it has to do with the way the
application interfaces are defined.

The original design of the application interfaces was that
UIMAFramework.produceAnalysisEngine throws
ResourceInitializationException and AnalysisEngine.reconfigure throws
ResourceConfigurationException.  That seemed sensible at the time...
and this can't be changed without breaking compatibility.

Because UIMAFramework.produceAnalysisEngine throws only
ResourceInitializationException, if we allowed the annotator's
initialize method to throw a different kind of exception, it would
just have to later be wrapped in a ResourceInitializationException
anyway.  But... I guess it's OK with me to do this if you think it
makes sense.

AnalysisEngine.reconfigure, OTOH, throws only
ResourceConfigurationException.  So in this case if the annotator
throws ResourceConfigurationException it can be passed all the way out
to the application.  But it's inconvenient not to allow the annotator
to throw ResourceInitializationException as well, since the default
implementation of reconfigure() is to call initialize()... so in this
case I did have the framework do the necessary wrapping.

This would all be a lot easier if we had used fewer exception types,
or used unchecked exceptions (which is the way a lot of Java
frameworks are going these days).  So my strategy in v2 was to try to
reduce the number of exception types and reduce the amount of
exception-wrapping that occurs.

-Adam