RE: XmlRepresentation.internalEval

[Jerome Louvel]

Sent too quickly... The reason for not declaring the exception is just for
convenience here, not forcing the developer to catch an exception where
there is little he will be able to do at runtime, bloating his source code.

For the 'final' keyword usage, it might save a bit of memory at most. No big
gain here I suspect. 

Best regards,
Jerome

-----Message d'origine-----
De : Jerome Louvel 
Envoyé : mardi 14 octobre 2008 20:37
À : discuss@restlet.tigris.org
Objet : RE: XmlRepresentation.internalEval


Hi Richard,

Thanks for the report. Your suggestion makes sense, so now we rethrow the
exceptions as you suggested. Checked in SVN trunk.

Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-----Message d'origine-----
De : Richard Hoberman [mailto:[EMAIL PROTECTED] 
Envoyé : lundi 13 octobre 2008 12:18
À : discuss@restlet.tigris.org
Objet : XmlRepresentation.internalEval

Hi

Here is a snippet of code from a failing test case:

1   DomRepresentation results = response.getEntityAsDom();
2   System.out.println(response.getEntityAsForm());  // temporary output
while writing test
3   NodeSet nodes = results.getNodes("/a/b/c");
4   Assert.assertNotNull(nodes); // fails

This test fails on line 4 - unexpectedly given the test document.  Some
debugging reveals the input stream is null
(java.lang.IllegalArgumentException: InputStream cannot be null) but the
exception was being swallowed by the catch clause in this method:

private Object internalEval(String expression, QName returnType) {
        try {
            return evaluate(expression, returnType);
        } catch (final Exception e) {
            return null;
        }
    }

I'm assuming that the input stream was null because I had consumed the
representation in line 2 (it works if I take this out).  But the method
behaves as if the xpath fails to match an element.

Is there a reason for not throwing the exception?  If the reason is to
sensibly avoid declaring an unhandleble exception, how about wrapping
non-runtime exceptions like this:

private Object internalEval(String expression, QName returnType) {
        try {
            return evaluate(expression, returnType);
        } catch(final RuntimeException e) {
           throw e;
        } catch (final Exception e) {
            throw new RuntimeException(e);
        }
    }


Best regards

Richard Hoberman

P.S.  What is the reason for marking the exception as final?  I haven't
come across this sort of thing before.