[
https://issues.apache.org/jira/browse/DISCOVERY-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13017414#comment-13017414
]
Michael Rudolf commented on DISCOVERY-11:
-----------------------------------------
You are right, of course the user needs to know about the errors. Therefore,
they should surely be logged. However, without catching these errors a single
faulty service provider can crash the whole system or at least prevent the
application from using other service providers.
Faults should generally not propagate until the user sees an error message,
they should be contained to the smallest realm possible. In this case, the
application should continue to work, except that the faulty service provider
will not provide any service.
An ideal solution would be to make the behavior configurable, so that
programmers can decide what to do depending on the service. For example, it
does not make sense for an application to continue operating normally if a
crucial service cannot be provided. If there is more than one provider for a
service, the application should continue and maybe display a warning about not
being able to load a certain service provider.
> Service.providers Enumeration does not catch and discard
> UnsatisfiedLinkErrors and ExceptionInInitializerErrors
> ---------------------------------------------------------------------------------------------------------------
>
> Key: DISCOVERY-11
> URL: https://issues.apache.org/jira/browse/DISCOVERY-11
> Project: Commons Discovery
> Issue Type: Bug
> Affects Versions: 0.4
> Environment: Windows, Sun JDK 1.5.0.10
> Reporter: Michael Rudolf
>
> The enumeration created by Service.providers does not catch
> UnsatisfiedLinkErrors and ExceptionInInitializerErrors. The former can arise,
> if a class contains a call to System.loadLibrary(String) in its static
> initializer, while the latter will be thrown, when a runtime exception is
> thrown from the static initializer. Service.providers should catch and ignore
> these and it should simply discard the class provoking the error as not
> available. As of version 0.4, Commons Discovery just forwards these errors.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
