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