I know that this is something I'm abusing by treating it like a lifecycle hook. I asked just-in-case you thought it had any impact on the design before it gets released.
I had been thinking that exception checking would be similar to how Environment.isInAttemptBlock() is used. So within TemplateProcessingTracer.exitElement I could do: if ( !env.hasExceptionBeenHandled() ) { ... // Insert code here } Where the implementation of hasExceptionBeenHandled would just check if lastThrowable was non-null: Your suggestion of an additional exception hook/method in TemplateProcessingTracer would also be a good solution. Again, I don't desperately need anything, I'm just nit-picking an API since it's about to be made public. Thank you for your feedback and time, Simon On Saturday, 6 April 2024 at 12:35:02 BST, Daniel Dekany <daniel.dek...@gmail.com> wrote: I believe TemplateProcessingTracer won't be used by 99.9...% percent of applications, so I added it with the assumption that its impact on performance and code complexity is practically nothing. And so, it's hooked in inside Environment.pushElement and popElement. And the pattern of calling those is like: pushElement() try { ... } finally { popElement(); } Therefore, popElement is not aware if there was an exception. Of course, I could make it aware, but as far as I see, you can't do it without introducing runtime overhead: pushElement() boolean popElementWasCalled = false; try { ... } catch (Throwable e) { popElementWasCalled = true; popElement(e); throw e; } finally { if (!popElementWasCalled) { popElement(null); } } Maybe it still won't matter for anyone... Not sure, but again then I'm risking things for a very rare use case. Another approach is this: pushElement() try { ... } catch (Throwable e) { if (templateProcessingTracer != null) { templateProcessingTracer.exception(env, e); } throw e; } finally { popElement(null); } In which case it's more difficult for the TemplateProcessingTracer implementation, as it has later associate the exception event with the TemplateProcessingTracer.exitElement call, but maybe that's OK, given how rarely TemplateProcessingTracer will be implemented. Regarding passing the TracedElement to emplateProcessingTracer.exitElement, that's possible to add. And then also to emplateProcessingTracer.exception, if we add that method. On Fri, Apr 5, 2024 at 5:54 PM Simon Hartley <scrhart...@yahoo.co.uk.invalid> wrote: > > I currently have the following (I'm only interested in the end of the > template.): > > env.setTemplateProcessingTracer(new TemplateProcessingTracer() { > int depth; > public void enterElement(Environment env, TracedElement tracedElement) { > depth++; > } > public void exitElement(Environment env) { > depth--; > if (depth == 0) { > ... // Code goes here > } > } > }); > > Is there a way for exitElement to know that there has been an exception in > the template and so it shouldn't do anything? > At the moment it seems to get called unconditionally. > Or is there a different way to hook into the processing? > > P.S. > (I was surprised that exitElement doesn't also take a TracedElement > parameter, but it isn't a problem.) > > Cheers, > Simon -- Best regards, Daniel Dekany