Wie man Fehlerprotokoll in einer Schablone in eXist-db, nicht außerhalb davon zeigt?

Question

Im Controller habe ich:

Normalerweise hilft dies, wenn ein Templat-Funktion (wie <div class="app:list-journals"/>) ausfällt. Wie man das für irgendeine Funktion benutzt, die auf dem Hintergrund fehlschlägt (z. B. nach dem Einreichen eines Formulars)?

UPDATE

Hier ist der Code, wo ich den Fehler der Templat-Funktion zu fangen versuchen:

... 
} catch * { 
     <error>Error {$err:code}: {$err:description}</error> 
} 

Dies funktioniert nicht. Die App verwendet immer noch ihre eigenen Protokolle als reine XML-Antworten.

Oder ich würde dies erwarten:

... 
} catch * { 
    logger:add-log-message(concat('Error: ', $err:code, $err:description)) 
} 

... mit einigen Umleiten zu einer globalen Fehlerseite funktionieren könnte, aber es funktioniert nicht. Sobald der Fehler nicht das Problem der App, sondern zum Beispiel eines XSLT-Prozesses ist, ist es nicht möglich, die App auf eine globale Seite umzuleiten, wie in dem Buch von A. Retter beschrieben (es ist notwendig, $EXIST_HOME/webapp/WEB-INF/web.xml zu verwenden) Datei und dort, um den Fehler und die bestimmte Seite für die Umleitung zu beschreiben).

Weitere Informationen, kein Fortschritt.

Answer 1

Nun, diese Frage ist ziemlich plump und die Antwort muss ein wenig umständlich sein. Das Problem ist, dass mir einige Dinge in Bezug auf Fehler und deren Beziehung zu XQuerys und eXists Template-Modul nicht bekannt waren.

Es scheint, gibt grundsätzlich drei Ebenen von Fehlern, die ich mit auf der Oberfläche umgehen können:

1 - Fehler im Zusammenhang mit Templating Diese Fehler sind am einfachsten zu lösen. Es genügt, einen Fehlerhandler in Ihrem Controller für URL-Rewriting (im Allgemeinen oder für eine bestimmte Seite) zu definieren:

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> 

Wenn eine Funktion im Zusammenhang mit Templating fehlschlägt, wird das Protokoll innerhalb eines Rahmens gezeigt, und es sieht aus wie ein gemeinsamer Teil Ihrer App-Seite:

2 - Fehler mit einigem speziellen HTTP-Code über Jetty zugeordnet

Diese Fehler sind Von Jetty protokolliert - die Seite verschwindet und stattdessen gibt es normalerweise ein langes Protokoll. Es ist möglich, eine Aufzeichnung eines solchen Fehlers in der $EXIST_HOME/webapp/WEB-INF/web.xml zu machen:

<error-page> 
    <error-code>404</error-code> 
    <location>/db/central/page404.xq</location> 
</error-page> 

Die location sollte logisch, zeigen Sie auf einer realen Seite innerhalb der App. Und wir können nicht in unserem controller.xql seiner Definition vergessen:

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> 

Diese Lösung ist nützlich, wenn Sie wissen, über Fehler zu wiederholen Sie freundlicher Benutzer machen wollen.Großartig für HTTP 404 oder HTTP 500 Fehler. HTTP 500 Fehler sind das größte Problem, weil die mit Fehlern verbunden sind, die von Funktionen ausgeführt werden. Nette Lösung.

3 - der Rest

In XQuery gibt es several types of errors. Für dynamische Fehler (während der Laufzeit ausgelöst und protokolliert als HTTP 500 Fehler von Jetty) ist es möglich, try/catch Anweisungen zu verwenden. Mit ihnen ist es möglich, Protokolle zu erfassen und sie irgendwo in Ihrer App zu speichern. Wenn Sie sie wie ich in der Nummer behandeln, ist es genug. Andere Arten von Fehlern sind (aus meiner Sicht) viel schwieriger zu fangen (statisch, getippt usw.). Dies bedeutet, es gibt keinen einfachen Weg, wie für Benutzer verstecken. Das Plus ist, dass Sie normalerweise früher während des Prototyping und des Testens wissen.

Vielleicht gibt es eine komplexe Möglichkeit, alle Fehler in einer freundlichen Art zu zeigen, aber es ist außerhalb von Raum und Zeit dieses Forums. Inspiration ist in Demo apps. Solch eine Lösung kann ein bisschen zeitaufwendig sein und es ist ein bisschen künstliches Problem im Moment.

Alle Erläuterungen und Argumente werden sehr geschätzt.