tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r976122 - in /websites/production/tapestry/content: cache/main.pageCache runtime-exceptions.data/Exception_Ajax.png runtime-exceptions.html
Date Tue, 22 Dec 2015 06:19:54 GMT
Author: buildbot
Date: Tue Dec 22 06:19:54 2015
New Revision: 976122

Log:
Production update by buildbot for tapestry

Added:
    websites/production/tapestry/content/runtime-exceptions.data/Exception_Ajax.png   (with
props)
Modified:
    websites/production/tapestry/content/cache/main.pageCache
    websites/production/tapestry/content/runtime-exceptions.html

Modified: websites/production/tapestry/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.

Added: websites/production/tapestry/content/runtime-exceptions.data/Exception_Ajax.png
==============================================================================
Binary file - no diff available.

Propchange: websites/production/tapestry/content/runtime-exceptions.data/Exception_Ajax.png
------------------------------------------------------------------------------
    svn:mime-type = image/png

Modified: websites/production/tapestry/content/runtime-exceptions.html
==============================================================================
--- websites/production/tapestry/content/runtime-exceptions.html (original)
+++ websites/production/tapestry/content/runtime-exceptions.html Tue Dec 22 06:19:54 2015
@@ -59,7 +59,7 @@
       </div>
 
       <div id="content">
-                <div id="ConfluenceContent"><p>Feedback is vitally important
when developing an application, and that is one of the areas where Tapestry has always excelled.</p><p>Especially
during development, requests can fail. There can be errors in templates, broken code in your
application, or something unexpected.</p><p>Tapestry has a built-in exception
report page that captures an amazing wealth of information:</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image confluence-content-image-border"
width="500" src="runtime-exceptions.data/Exception%20-%20Stack%20Trace%20.png"></span></p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="confluence-embedded-image
confluence-content-image-border" width="500" src="runtime-exceptions.data/Exception%20-%20Request.png"></span></p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="c
 onfluence-embedded-image confluence-content-image-border" height="443" width="500" src="runtime-exceptions.data/Application_Exception.png"></span></p><p>This
exception report features:</p><ul><li>The full stack of exceptions, top
to bottom.</li><li>All non-null properties of each exception.</li><li>The
stack trace&#160;<em>at the deepest level</em>.</li><li>Key&#160;<strong>request</strong>
properties, header, attributes, and parameters.</li><li>Key&#160;<strong>session</strong><em>&#160;</em>propertes</li><li>A
break down of the&#160;<em>thread</em> in your application</li><li>A
listing of all JVM System properties<br clear="none"><br clear="none"></li></ul><p>In
addition, Tapestry will write a text file for the exception with a similar level of detail.</p><p>This
exception report is also built-in to Tapestry's Ajax support. When an Ajax request fails,
Tapestry's client-side code will create an &lt;iframe&gt; to present this same information:</p><p><span
class="confluence-embedded-
 file-wrapper confluence-embedded-manual-size"><img class="confluence-embedded-image
confluence-content-image-border" height="359" width="500" src="runtime-exceptions.data/Exception%20-%20Ajax.png"></span></p><p>In
production, you may want to <a  href="overriding-exception-reporting.html">override
the exception report page</a> (but will likely keep the text file output). However,
Tapestry's (from version 5.4) default exception reporter also allows you to handle specific
exception types in a pre-determined manner, similar to how servlet spec's standard error-page/exception-type
configuration option allows you to map exception types to URLs. At times, it's simpler to
just catch exceptions at the outermost layer of your application instead of carrying a typed
exception through multiple layers of abstractions just so you could show a sensible error
message to the user, especially if you can't do anything more clever about it anyway. Exception
type mapping in Tapestry is much more powerfu
 l than what the servlet spec dictates. If your email service or an external payment service
goes down, you can't do much more than display an error message to the user, so why would
you need to implement separate pages for each exception? Often, it'd be nicer if you could
just reuse the page template for any fatal exception and simply display a different error
message. In addition to contributing handlers for specific types of exceptions, you may also
provide context for rendering the same error page template with a different output.</p><p>&#160;</p><p>You
can contribute an error page, mapping it to an exception type:</p><p>&#160;&#160;
&#160;public void contributeExceptionHandler(MappedConfiguration&lt;Class, Class&gt;
configuration) {</p><p>&#160;&#160; &#160;&#160;&#160; &#160;configuration.add(SmtpNotRespondingException.class,
ServiceFailure.class);</p><p>&#160;&#160; &#160;}</p><p>&#160;</p><p>If
a simple exception type to page mapping doesn't do it for you, you can also contri
 bute a custom handler for that particular exception type. An ExceptionHandlerAssistant can
contain arbitrarily complex logic for handling a specific exception type and use other Tapestry
services. If ExceptionHandlerAssistant.handleRequestException(Throwable exception, List&lt;Object&gt;
exceptionContext) returns an Object representing an URL the main handler will issue a redirect
to that URL. It's valid to return either a String, a Link or a Class; the last case implies
a page class. If the ExceptionHandlerAssistant returns null, it's assumed that the assistant
has independently handled the exception. You can either contribute an instance of an ExceptionHandlerAssistant
or a class that implements ExceptionHandlerAssistant. Below, we contribute an instance handling
ServiceExceptions:</p><p>&#160;&#160; &#160;public void contributeExceptionHandler(OperationQueue
operationQueue, MappedConfiguration&lt;Class, Class&gt; configuration) {</p><p>&#160;&#160;
&#160;&#160;&#160; &#160;final 
 ExceptionHandlerAssistant assistant = new ExceptionHandlerAssistant() {</p><p>&#160;&#160;
&#160;&#160;&#160;&#160; @Override</p><p>&#160;&#160;
&#160;&#160;&#160;&#160; public Object handleRequestException(Throwable exception,
List&lt;Object&gt; exceptionContext) throws IOException {</p><p>&#160;&#160;
&#160;&#160;&#160;&#160;&#160;&#160; ServiceException serviceException
= (ServiceException)exception;</p><p>&#160;&#160; &#160;&#160;&#160;&#160;&#160;&#160;
if (serviceException.isInterruptedOperationRecoverable()) {</p><p>&#160;&#160;
&#160;&#160;&#160;&#160;&#160; &#160;&#160;&#160; &#160;operationQueue.add(serviceException.getInterruptedOperation());</p><p>&#160;&#160;
&#160;&#160;&#160;&#160;&#160; &#160;&#160;&#160; &#160;return
OperationScheduled.class;</p><p>&#160;&#160; &#160;&#160;&#160;&#160;&#160;&#160;
}</p><p>&#160;&#160; &#160;&#160;&#160;&#160;&#160;&#160;
else return ServiceUnavailable.class;</p><p>&#160;&#160; &#160;&#160;&#160;&#160;
}</p><p>&#160;&#160; &#160;&#16
 0;&#160; &#160;};</p><p>&#160;&#160; &#160;&#160;&#160;
&#160;configuration.add(ServiceException.class, assistant);</p><p>&#160;&#160;
&#160;}</p><p>&#160;</p><p>You can also specify context for
the exception page. For generic exceptions, the context is taken from the exception class
name minus the word "Exception" in case that's how the class name ends. For example, you have
a following class:</p><p>&#160;</p><p>&#160;&#160; &#160;public
class SmtpNotRespondingException extends RuntimeException {</p><p>&#160;&#160;
&#160;&#160;&#160; &#160;...</p><p>&#160;&#160; &#160;}</p><p>&#160;</p><p>If
an SmtpNotRespondingException is thrown during an action request, user is directed to ServiceFailure
page with a String context smtpnotresponding (i.e. to URL **/servicefailure/smtpnotresponding**).
Tapestry-exceptionpage works both for regular action requests and ajax action requests. In
the latter case, the module will use Javascript to redirect to the error page. If the exception
thrown wasn
 't an explicitly specified exception type (i.e. a contributed type), handling is delegated
back to the default Tapestry exception handler.</p><p>If your custom-handled exception
implements the interface *ContextAwareException* you can fully specify the context for the
error page. For example, you could implement a following Exception class:</p><p>&#160;&#160;
&#160;public class SmtpNotRespondingException extends RuntimeException implements ContextAwareException
{</p><p>&#160;&#160; &#160;&#160;&#160; &#160;private
Object[] context;&#160;&#160;</p><p>&#160;&#160; &#160;&#160;&#160;
&#160;public EmailServiceException(Object[] context) {</p><p>&#160;&#160;
&#160;&#160;&#160; &#160;&#160;&#160; &#160;super();</p><p>&#160;&#160;
&#160;&#160;&#160; &#160;&#160;&#160; &#160;this.context = context;</p><p>&#160;&#160;
&#160;&#160;&#160; &#160;}</p><p>&#160;&#160; &#160;&#160;&#160;
&#160;// Defined in ContextAwareException interface</p><p>&#160;&#160;
&#160;&#160;&#160; &#160;public Object[]
  getContext() {</p><p>&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160;
&#160;return context;</p><p>&#160;&#160; &#160;&#160;&#160;
&#160;}</p><p>&#160;&#160; &#160;}</p><p>&#160;</p><p>This
exception handling mechanism can easily be overused. Typically, if you can handle the exception
locally, you should. Likewise, you shouldn't blindly wrap any checked exceptions inside runtime
exceptions just to avoid writing try-catch blocks in higher layers. The exceptionpage module
is best used for handling serious but rarely occurring exceptions happening in the action
request cycle that you cannot otherwise cope with.</p></div>
+                <div id="ConfluenceContent"><p>Feedback is vitally important
when developing an application, and that is one of the areas where Tapestry has always excelled.</p><p>Especially
during development, requests can fail. There can be errors in templates, broken code in your
application, or something unexpected.</p><p>Tapestry has a built-in exception
report page that captures an amazing wealth of information:</p><p><span class="confluence-embedded-file-wrapper
confluence-embedded-manual-size"><img class="confluence-embedded-image confluence-content-image-border"
width="500" src="runtime-exceptions.data/Exception%20-%20Stack%20Trace%20.png"></span></p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="confluence-embedded-image
confluence-content-image-border" width="500" src="runtime-exceptions.data/Exception%20-%20Request.png"></span></p><p><span
class="confluence-embedded-file-wrapper confluence-embedded-manual-size"><img class="c
 onfluence-embedded-image confluence-content-image-border" height="443" width="500" src="runtime-exceptions.data/Application_Exception.png"></span></p><p>This
exception report features:</p><ul><li>The full stack of exceptions, top
to bottom.</li><li>All non-null properties of each exception.</li><li>The
stack trace&#160;<em>at the deepest level</em>.</li><li>Key&#160;<strong>request</strong>
properties, header, attributes, and parameters.</li><li>Key&#160;<strong>session</strong><em>&#160;</em>propertes</li><li>A
break down of the&#160;<em>thread</em> in your application</li><li>A
listing of all JVM System properties<br clear="none"><br clear="none"></li></ul><p>In
addition, Tapestry will write a text file for the exception with a similar level of detail.</p><p>This
exception report is also built-in to Tapestry's Ajax support. When an Ajax request fails,
Tapestry's client-side code will create an &lt;iframe&gt; to present this same information:</p><p><span
class="confluence-embedded-
 file-wrapper confluence-embedded-manual-size"><img class="confluence-embedded-image
confluence-content-image-border" height="359" width="500" src="runtime-exceptions.data/Exception_Ajax.png"></span></p><p>In
production, you may want to <a  href="overriding-exception-reporting.html">override
the exception report page</a> (but will likely keep the text file output). However,
Tapestry's (from version 5.4) default exception reporter also allows you to handle specific
exception types in a pre-determined manner, similar to how servlet spec's standard error-page/exception-type
configuration option allows you to map exception types to URLs. At times, it's simpler to
just catch exceptions at the outermost layer of your application instead of carrying a typed
exception through multiple layers of abstractions just so you could show a sensible error
message to the user, especially if you can't do anything more clever about it anyway. Exception
type mapping in Tapestry is much more powerful than
  what the servlet spec dictates. If your email service or an external payment service goes
down, you can't do much more than display an error message to the user, so why would you need
to implement separate pages for each exception? Often, it'd be nicer if you could just reuse
the page template for any fatal exception and simply display a different error message. In
addition to contributing handlers for specific types of exceptions, you may also provide context
for rendering the same error page template with a different output.</p><p>&#160;</p><p>You
can contribute an error page, mapping it to an exception type:</p><p>&#160;&#160;
&#160;public void contributeExceptionHandler(MappedConfiguration&lt;Class, Class&gt;
configuration) {</p><p>&#160;&#160; &#160;&#160;&#160; &#160;configuration.add(SmtpNotRespondingException.class,
ServiceFailure.class);</p><p>&#160;&#160; &#160;}</p><p>&#160;</p><p>If
a simple exception type to page mapping doesn't do it for you, you can also contribute a
  custom handler for that particular exception type. An ExceptionHandlerAssistant can contain
arbitrarily complex logic for handling a specific exception type and use other Tapestry services.
If ExceptionHandlerAssistant.handleRequestException(Throwable exception, List&lt;Object&gt;
exceptionContext) returns an Object representing an URL the main handler will issue a redirect
to that URL. It's valid to return either a String, a Link or a Class; the last case implies
a page class. If the ExceptionHandlerAssistant returns null, it's assumed that the assistant
has independently handled the exception. You can either contribute an instance of an ExceptionHandlerAssistant
or a class that implements ExceptionHandlerAssistant. Below, we contribute an instance handling
ServiceExceptions:</p><p>&#160;&#160; &#160;public void contributeExceptionHandler(OperationQueue
operationQueue, MappedConfiguration&lt;Class, Class&gt; configuration) {</p><p>&#160;&#160;
&#160;&#160;&#160; &#160;final Except
 ionHandlerAssistant assistant = new ExceptionHandlerAssistant() {</p><p>&#160;&#160;
&#160;&#160;&#160;&#160; @Override</p><p>&#160;&#160;
&#160;&#160;&#160;&#160; public Object handleRequestException(Throwable exception,
List&lt;Object&gt; exceptionContext) throws IOException {</p><p>&#160;&#160;
&#160;&#160;&#160;&#160;&#160;&#160; ServiceException serviceException
= (ServiceException)exception;</p><p>&#160;&#160; &#160;&#160;&#160;&#160;&#160;&#160;
if (serviceException.isInterruptedOperationRecoverable()) {</p><p>&#160;&#160;
&#160;&#160;&#160;&#160;&#160; &#160;&#160;&#160; &#160;operationQueue.add(serviceException.getInterruptedOperation());</p><p>&#160;&#160;
&#160;&#160;&#160;&#160;&#160; &#160;&#160;&#160; &#160;return
OperationScheduled.class;</p><p>&#160;&#160; &#160;&#160;&#160;&#160;&#160;&#160;
}</p><p>&#160;&#160; &#160;&#160;&#160;&#160;&#160;&#160;
else return ServiceUnavailable.class;</p><p>&#160;&#160; &#160;&#160;&#160;&#160;
}</p><p>&#160;&#160; &#160;&#160;&#16
 0; &#160;};</p><p>&#160;&#160; &#160;&#160;&#160; &#160;configuration.add(ServiceException.class,
assistant);</p><p>&#160;&#160; &#160;}</p><p>&#160;</p><p>You
can also specify context for the exception page. For generic exceptions, the context is taken
from the exception class name minus the word "Exception" in case that's how the class name
ends. For example, you have a following class:</p><p>&#160;</p><p>&#160;&#160;
&#160;public class SmtpNotRespondingException extends RuntimeException {</p><p>&#160;&#160;
&#160;&#160;&#160; &#160;...</p><p>&#160;&#160; &#160;}</p><p>&#160;</p><p>If
an SmtpNotRespondingException is thrown during an action request, user is directed to ServiceFailure
page with a String context smtpnotresponding (i.e. to URL **/servicefailure/smtpnotresponding**).
Tapestry-exceptionpage works both for regular action requests and ajax action requests. In
the latter case, the module will use Javascript to redirect to the error page. If the exception
thrown wasn't an 
 explicitly specified exception type (i.e. a contributed type), handling is delegated back
to the default Tapestry exception handler.</p><p>If your custom-handled exception
implements the interface *ContextAwareException* you can fully specify the context for the
error page. For example, you could implement a following Exception class:</p><p>&#160;&#160;
&#160;public class SmtpNotRespondingException extends RuntimeException implements ContextAwareException
{</p><p>&#160;&#160; &#160;&#160;&#160; &#160;private
Object[] context;&#160;&#160;</p><p>&#160;&#160; &#160;&#160;&#160;
&#160;public EmailServiceException(Object[] context) {</p><p>&#160;&#160;
&#160;&#160;&#160; &#160;&#160;&#160; &#160;super();</p><p>&#160;&#160;
&#160;&#160;&#160; &#160;&#160;&#160; &#160;this.context = context;</p><p>&#160;&#160;
&#160;&#160;&#160; &#160;}</p><p>&#160;&#160; &#160;&#160;&#160;
&#160;// Defined in ContextAwareException interface</p><p>&#160;&#160;
&#160;&#160;&#160; &#160;public Object[] getCo
 ntext() {</p><p>&#160;&#160; &#160;&#160;&#160; &#160;&#160;&#160;
&#160;return context;</p><p>&#160;&#160; &#160;&#160;&#160;
&#160;}</p><p>&#160;&#160; &#160;}</p><p>&#160;</p><p>This
exception handling mechanism can easily be overused. Typically, if you can handle the exception
locally, you should. Likewise, you shouldn't blindly wrap any checked exceptions inside runtime
exceptions just to avoid writing try-catch blocks in higher layers. The exceptionpage module
is best used for handling serious but rarely occurring exceptions happening in the action
request cycle that you cannot otherwise cope with.</p></div>
       </div>
 
       <div class="clearer"></div>



Mime
View raw message