For the first situation, I would convert it to a runtime exception, perhaps
ProviderException (even though we are not an spi provider), or
IllegalStateException, or even an Error, like AssertionError as this really
is a precondition we are asserting. This is an irrecoverable condition of
the application itself, nothing the user could do about it. That way if we
break something we could get a useful error...
On Feb 18, 2016 1:27 AM, "Emmanuel Lécharny" <[email protected]> wrote:
> Le 18/02/16 06:49, Emmanuel Lécharny a écrit :
> > Hi,
> >
> > yesterday, we had a quick chat with Radovan about the fact that some
> > constructors are throwing an Exception, like the DefaultSchemaManager().
> >
> > Actually, all of the 4 DefaultSchemaManager throw an Exception, but we
> > can easily get rid of the 'throw' for 3 of them. The question is what
> > should we do with the default constructor ? The thrown Exception is the
> > one thrown when we intialise it :
> >
> > public DefaultSchemaManager() throws Exception
> > {
> > ...
> > loadAllEnabled(); <---- This is throwing an Exception
> > }
> >
> > It makes little sense to thrown an exception in this case : the default
> > schema is not going to be altered in this very case (the default
> > constructor) because it's part of the API as a Jar file we provide. If
> > this jar file is incorrect, then the full API is incorrect.
> >
> > I would suggest we stop throwing an Exception, and catch the one thrown
> > by loadAllEnabled() in the constructor, logging some message (which will
> > never happend anyway).
> >
> > There is also a second change I'd like to do : everywhere we throw an
> > Exception in the API, we should at least throw a LdapException instead.
> >
> > wdyt ?
> Note that the problem also hits the SchemaLoader classes. Although it's
> harder to get rid of the constructor's exceptions in this case, we can
> at least make the methods and constructors throw meaningfull exceptions,
> like LdapException and IOException instead of the generic Exception...
>
