Rationale behind GadgetException

[Gagandeep singh <ga...@gmail.com>]

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
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

Re: Rationale behind GadgetException

[Gagandeep singh <ga...@gmail.com>]

I guess this makes sense. Had there not been an NullPointerException, i
might not have noticed the error case at all :)

2010/7/22 ๏̯͡๏ Jasvir Nagra <ja...@google.com>

> On Wed, Jul 21, 2010 at 1:59 PM, Gagandeep singh <gagan.goku@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
> >
>

Re: Rationale behind GadgetException

[๏̯͡๏ Jasvir Nagra <ja...@google.com>]

On Wed, Jul 21, 2010 at 1:59 PM, Gagandeep singh <ga...@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
>

Re: Rationale behind GadgetException

[John Hjelmstad <fa...@google.com>]

Hi Gagan:

It sounds like you want the ability, in certain pieces of code, to catch
certain RuntimeExceptions and convert them using GadgetException(Code,
Throwable, String) to a checked GadgetException?

If so, I'd say we should choose to do this on a case-by-case basis --
depending on the context and the particular exception. The example you give
sounds reasonable, as a way to produce a more meaningful error message in a
fairly well-known case. But in other situations, I'd advocate catching
RuntimeException at a much higher level of processing, to do the same thing.

--j

On Wed, Jul 21, 2010 at 1:59 PM, Gagandeep singh <ga...@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
> 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
>