How to show error log in a template in eXist-db, not outside of it? - exist-db

Question

In the controller I have:
else if (ends-with($exist:resource, ".html")) then
(: the html page is run through view.xql to expand templates :)
<dispatch xmlns="http://exist.sourceforge.net/NS/exist">
<view>
<forward url="{$exist:controller}/modules/view.xql">
<set-header name="Cache-Control" value="no-cache"/>
</forward>
</view>
<error-handler>
<forward url="{$exist:controller}/error-page.html" method="get"/>
<forward url="{$exist:controller}/modules/view.xql"/>
</error-handler>
</dispatch>
Typically, this helps when a templating function fails (like <div class="app:list-journals"/>). How to use that for any function failing on the background (e.g. after submission of a form)?
UPDATE
Here is the code where I am trying to catch the error of the templating function:
...
} catch * {
<error>Error {$err:code}: {$err:description}</error>
}
This does not work. The app still uses its own logs as bare XML responses.
Or I would expect this:
...
} catch * {
logger:add-log-message(concat('Error: ', $err:code, $err:description))
}
... could work with some redirecting to a global error page but it does not. As soon as the error is not the problem of the app but, let's say, of a XSLT process, it is not possible to redirect the app to some global page as described in the book by A. Retter (it is necessary to use $EXIST_HOME/webapp/WEB-INF/web.xml file and there to describe the error and the particular page for redirecting).
More information, no progress.

Answer 1

Well, this question is rather clumsy and the answer has to be a bit cumbersome. The problem is I was not aware of several things regarding to errors and their relationship with XQuery and eXist’s templating module.
It seems there are basically three levels of errors I can deal with on the surface:
1 — errors associated with templating
These errors are the easiest to solve. It is enough to define an error handler in your controller for URL rewriting (in general or for a particular page):
else if (ends-with($exist:resource, ".html")) then
<dispatch xmlns="http://exist.sourceforge.net/NS/exist">
<view>
<forward url="{$exist:controller}/modules/view.xql">
<set-header name="Cache-Control" value="no-cache"/>
</forward>
</view>
<error-handler>
<forward url="{$exist:controller}/error-page.html" method="get"/>
<forward url="{$exist:controller}/modules/view.xql"/>
</error-handler>
</dispatch>
If any function associated with templating fails, the log is showed inside a frame and it looks like a common part of your app page:
2 — errors associated with some special HTTP code via Jetty
These errors are logged by Jetty—the page disappears and instead of it there is usually a long log. It is possible to make a record of such an error in the $EXIST_HOME/webapp/WEB-INF/web.xml:
<error-page>
<error-code>404</error-code>
<location>/db/central/page404.xq</location>
</error-page>
The location should, logically, point to a real page inside of your app. And we can’t forget to its definition in our controller.xql:
else if ($exist:path eq 'error-404.html') then
<dispatch xmlns="http://exist.sourceforge.net/NS/exist">
<forward url="{$exist:controller}/errors/error-404.html"/>
<view>
<forward url="{$exist:controller}/modules/view.xql">
<set-header name="Cache-Control" value="no-cache"/>
</forward>
</view>
</dispatch>
This solution is useful if you know about repeating errors you want to make more friendly to users. Great for HTTP 404 or HTTP 500 errors. HTTP 500 errors are the biggest problem because the are associated with errors made by functions running. Nice solution.
3 — the rest
In XQuery, there are several types of errors. For dynamic errors (thrown during runtime and logged as HTTP 500 errors by Jetty) it is possible to use try/catch statements. With them, it’s possible to catch logs and to store them somewhere in your app. If you treat them like me in the number 2, it is enough. Other types of errors are (from my point of view) much harder to catch (static, typed and so on). This means there is no easy way how to hide them for users. The plus is you usually know about them earlier during prototyping and testing, anyway.
Maybe there is some complex possibility of showing all errors in a friendly way but it is outside of space and time of this forum. Inspiration is in Demo apps. Such a solution may be a bit time consuming and it’s a bit artificial problem at the moment.
Any clarifications and arguments are very appreciated.