0

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.

Honza Hejzl
  • 874
  • 8
  • 23
  • I'm not following your question. Could you expand on what you are trying to achieve? – Joe Wicentowski Apr 21 '16 at 11:35
  • Oh, sorry, I will try to rewrite it. I mean when there is an error of an `app:func` (templating function), I got the error log simple in the body of the web app. When there is an error on the background (typically of some transformation or so), I am thrown into a layout-less log. – Honza Hejzl Apr 21 '16 at 11:40
  • And this error on the background happens on a non-templating-based page? Assuming you don't want to make it into a templating page, have you used a "try catch" expression? – Joe Wicentowski Apr 21 '16 at 11:43
  • Typically: User submits a form, which triggers a bunch of actions on the background (e.g., collecting some entries, packing an epub), if this process fails, the app logs outside of templating, the log is only pure XML exposed to the browser. Sorry for my bad explanation. – Honza Hejzl Apr 21 '16 at 11:49
  • Oh, I should probably learn how to try/catch errors in a bit more complex functions… – Honza Hejzl Apr 23 '16 at 11:19
  • Maybe it would be good to rewrite the question because my intention is to hide any kind of error and let users know about it only via a note on friendly pages. And to log every error silently on the background. Too complex task, apparently. – Honza Hejzl Apr 23 '16 at 17:12

1 Answers1

0

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:

the error of a templating function

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.

Honza Hejzl
  • 874
  • 8
  • 23