Hrm, I've never had that much of a problem with dispatch() swallowing the cause... wonder what's going wrong there...
I couldn't remember the cost of adding try/catch - I knew it's very small, but couldn't remember how small (since CoreRenderer gets hit a lot, I'm paranoid), but: http://www.ujug.org/stuff/1522_performance_myths_exposed.pdf answers that question. (Short answer: except for *very* tight loops, esp. looping through arrays, it's essentially free.) That said, what I'm thinking we might do is try something a bit fancier to try and prevent the "half-HTML-half-stacktrace" syndrome - which is especially bad in XMLHttp, where you get "half-XML-half-stacktrace", which is as good as no XML at all, and defeats the efforts of the PPR system to do a good job with error cases. Have to think how that would work, but I'm toying with a ResponseWriter extension that can close up elements automatically and show the stack trace in some nicer form in debug mode, or in non-debug mode redirect to an error page. WDYT? -- Adam On 7/19/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
Hello all, Do you think it would be good to add a try-catch block to CoreRenderer's encodeEnd method that would catch RuntimeException as well as IOException to log the message before rethrowing them again? For EL errors you almost always get a decent stack trace. However, for other error I always seem to end up with a .dispatch() error swallowing the real cause and obviously what renderer failed. Right now I have to place a try-catch in the encodeAll method of all my custom components. Am I the only one with that problem? Regards, ~ Simon
