On Wed, Jul 21, 2010 at 1:59 PM, Gagandeep singh <gagan.g...@gmail.com>wrote:
> Hi
>
> Is there any rationale behind GadgetException extending Excepiton and thus
> not being able to encapsulate runtime exceptions like NullPointerException
> (checked vs unchecked exception) ?
> Would it make sense for it to do so ? I am running into some cases where
>
The usual reason for throwing an unchecked exception instead of a checked
one is if the exception is one which the user is not expected to be able to
recover from. GadgetException is an expected exception which code regularly
catches and recovers from. The only place that RuntimeExceptions should be
caught in a servlet is for rendering something nice to the enduser. If you
catch and suppress unchecked or turn them into checked ones which code
elsewhere catches, it'll hide cause continued execution when the program is
in an unexpected state.
There might be value in wrapping some unchecked exceptions in a known way
and catching that to distinguish unexpected errors in Shindig vs unexpected
errors in library code however. Caja fr'instance throws
c.g.caja.SomethingWidgyHappenedError runtime exception when it encounters a
situation which it doesn't expected to be able to recover from.
NullPointerException is throws all the way up to the stack and I was
> wondering if i could just make GadgetException catch these.
> For example, caja html parser sometimes throws NullPointerExceptions when
> the dom is being parsed in GadgetHtmlParser, where i plan on adding the
> lines in blue:
> if (document == null) { try { document = parseDomImpl(source); } catch
> (GadgetException e) { throw e; } catch (DOMException e) { // DOMException
> is
> a RuntimeException document = errorDom(e);
> HtmlSerialization.attach(document,
> serializerProvider.get(), source); return document; + } catch
> (NullPointerException e) { + throw new
> GadgetException(GadgetException.Code.INTERNAL_SERVER_ERROR, + "Caught
> exception in parseDomImpl", e); }
>
> Thoughts ?
>
> Thanks
> Gagan
>
