I have added a TracedElement parameter to exitElement.
I will look into the exception question sometimes later.
On Sat, Apr 6, 2024 at 8:02 PM Simon Hartley
<scrhart...@yahoo.co.uk.invalid> wrote:
>
> 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
>
--
Best regards,
Daniel Dekany
