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

Reply via email to