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 <[email protected]>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 >
