On 10/19/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: >...We define > an API for Sling (or microsling for that matter) applications, so the > most natural thing counting these two together is to require > SlingExceptions to be thrown....
Ok, considering other's comments here (thanks!) I have created SLING-75 to move to SlingException throughout the API. > ...So rather, I would suggest to define more specific exceptions if > required (e.g. if we think Resource resolution failure should be better > visible, define a ResourceResolutionException extends SlingException).... I usually try to do this so that exception class names carry meaningful information. But we shouldn't encumber the API with too many specific exception classes. I think (most of) the exception classes which extend SlingException can safely be defined at the implementation level: they won't be exposed in the API then, but someone seeing a ResourceResolutionException in their log will have more info than if it was a plain SlingException, so I think it's worth it. -Bertrand
