|
From: <jue...@we...> - 2004-12-22 14:26:42
|
Hi Patrick, =20 I assume you're referring to the JasperReportsUtils class here, as the = web view support does not require explicit exception handling in the = first place. =20 That utility class is meant to be used for non-web usage of = JasperReports, analogous to our existing VelocityEngineUtils and = FreeMarkerTemplateUtils classes. Like the latter two, it throws the = native exception of the respective tool. =20 In application code, such exceptions are supposed to be wrapped in = context-sensitive exceptions, for example MailPreparationException if = preparing mail context for use with Spring's mail support. Failure to = render templates should always result in meaningful error message for = the user, for example "could not generate annual report data for report = mail", instead of some "invalid expression in template file xxx" = message. =20 Of course, one could argue that generic RuntimeExceptions wouldn't hurt = here either. Usually template/report rendering is part of a larger = operation, though, so wrapping in a context-sensitive exception should = be a natural thing to do. =20 Juergen =20 ________________________________ Von: spr...@li... im Auftrag = von Patrick Burleson Gesendet: Di 21.12.2004 22:15 An: spr...@li... Betreff: [Springframework-developer] JasperReports Support So I was checking out the JasperReports support stuff in 1.1.3. Good work there. My only question is, why not wrap JS's checked Exception with a RuntimeException? JS Execptions don't seem to be too recoverable. Patrick ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |