Re: [xwiki-devs] [Proposal] Adding new velocity methods to simulate try/catch in Velocity

Hi, Interesting, though I do have my worries about having to deal with actual exceptions in velocity. Probably the most common usecase would be just to display the exception, but others may now be tempted to look at exception types and display custom messages for each error situation. That should improve the quality of the UIs, but at the same time I feel like it will increase the amount of velocity code in wiki pages. Generally, I`m +1 since I had to deal on some occasions with exception handling in velocity and found myself re-coding over and over again the methanism of passing the exception from the script service to the velocity UI. However, I feel there are some things that are could be done to improve it in practice: 1. Make sure that the "try" directive clears any existing context exception before executing it's content and possibly setting a new exception in the context. Example: #try() <some code> #end <handle $exception> #try() <some other code> #end <handle $exception, but which code's exception is this?> 2. Support nested exception handling. Example: #try() <some code> #try() <some nested code> #end <handle $exception> #end <handle $exception, but is it the nested exception or the main one?> I agree that this point (2.) could probably be solved by (1.) if the "try" directive clears the context exception *after* executing the code so that any leftovers from nested exceptions are cleared. 2.1. However, my initial suggestion was to maybe support "named exceptions" (i.e. a parameter for the "try" directive that could specify the variable where to expose the exception). Example: #try() <some code> #try("nestedException") <-- or #try($nestedException) but I think this is more problematic since it really has to be set to $NULL before <some nested code> #end <handle $nestedException> #end <handle $exception> 2.2 Thinking of the above and the nested usecase, I just wanted to mention a possible #throw($exception) directive in case we want to use the main "try" block as a catch-all handler, even if nested try blocks caught and reported errors as they occurred (so they would now bubble the exception towards the main try block to signal that the operation as a whole was problematic). Example: #try() <some code> #try() <some nested code> #end #if ($exception) <handle $exception> #throw($exception) <-- this probably stops the execution here. #end #end <catch-all handling of $exception> Of course, this can be done with a variable instead in the exception handling of each nested try blocks. Example: #try() <some code> #try() <some nested code> #end #if ($exception) <handle $exception> #set($failed=true) <-- this leaves the developer to decide by using some IFs. #end #end <handle of any $exception uncaught by the nested try blocks, also considering the $failed variable> Point 1. is a must IMO to avoid unwanted errors. The rest is just food for thought, perhaps you consider them useful as well. Thanks, Eduard On Fri, Sep 19, 2014 at 3:48 PM, vincent(a)massol.net &lt;vincent(a)massol.net&gt; wrote: