1. I would rather add proper directives instead of macros and uberspector hacks: http://stackoverflow.com/q/159292/620249
2. So far it has been the job of our scriptable wrappers to catch exceptions, does this proposal mean that: a. We should stop doing that and write try-catch logic in our templates/scripts? IOW, catching exceptions in wrappers is a bad design pattern? b. We didn't do that enough, and as a workaround we're adding exception handling in Velocity? On 09/18/2014 09:28 AM, [email protected] wrote: > Hi Devs, > > Example of a use case: > > * In contentview.vm we need to be able to catch when getRenderedContent() > throws an exception in order to be able to still display the page title, > content menu and last modification line. We want only the content part to > display an error. > > I’ve tried implementing the following: > * Modified Document.getRenderedContent() to not throw exceptions any more > * I’ve added Document.setError() and getError() > * Then added a #displayRenderedContent($renderedContent) velocimacro to > display an error, calling Document.getError() > > However that’s no good because we have lots of places in our code (and in > extensions we don’t control) that call getRenderedContent() and they expect > the whole page rendering to fail in case of an error… > > Thus after discussing quickly on IRC and with Thomas we’d like to propose > instead: > > * Add a new #try() velocimacro that would push a new empty List<Exception> in > the Execution Context to a Stack variable > * Add a new uberspector that would, based on this flag do a try/catch around > the method called (can be done easily by returning a custom VelMethod) > * The uberspector catch would add the exception to the List<Exception> in the > Execution Context > * Add a new #catch() velocimacro that would pop from the Stack in the > Execution Context and that would set 2 variables in the Velocity Context: > ** $exception: the first exception > ** $exceptions: the list of all exceptions that happened between the #try() > and #catch() > > The good part with this is: > * No change in behavior to all existing code > * Code that want to do something in case of error can do it using > #try()/#catch() for java methods throwing exceptions (like > getRenderedContent()) > > Of course for the future we would need to decide if script services should > stop doing try/catch or not but that’s another debate I’d prefer to separate > from this thread. > > WDYT? > > Thanks > -Vincent > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
