OPS, like many Java platforms and applications, has to deal with exceptional conditions occurring at runtime: an XML file may be ill-formed and cause parsing errors; a Page Flow configuration may be incorrect; an XSLT stylesheet or an XForms page may contain incorrect markup; and so on.
In such cases a Java exception is raised and propagated up the Java method call stack. For practical reasons, such as adding more meaningful error messages, the initial exception is sometimes encapsulated within other exceptions. Finally, a top-level exception handler catches and formats the exceptions for presentation to the developer or for logging purposes.
Java stack traces are certainly useful for the developer who writes Java code: they provide information about the name of the Java source file, as well as line and column information. However in most situations the developer writing an application on top of OPS does not write the incriminated Java code, and instead really cares instead about XML file names and location information related to those files. This is why whenever possible OPS provides location data wrapped into a
ValidationException Java exception.
This was pretty good but a recent blog entry by Sylvain Wallez has motivated some improvements to the error messages provided by OPS. A hierarchy of location data is in fact provided during the excecution of the OPS Page Flow Controller and XPL pipelines in general. Collecting and displaying this information amounts to creating an OPS stack trace showing the sequence of calls that have occurred until the exception was raised. This is absolutely invaluable information for the OPS developer.
Most of the code was already there and it was a breeze to enhance OPS to display stack traces more meaningful to an OPS user, such as the following:
This does not mean that Java stack traces are no longer shown, on the contrary, but a few cosmetic changes later, and the Java exceptions suddenly look much nicer:
Java stack traces are split into their different request components. For example, an exception may have been produced by a request on the
OPSServlet, forwarded again to
OPSServlet, then going through the OPS example portal's
OPSPortlet. In this case, the stack trace is split into three parts for clarity.
Some coloring is applied to the class names to easily distinguish OPS classes from third-party classes.
As OPS users may have noticed, Java stack traces can be quite long due to the streamed nature of the execution of XPL pipelines. Exceptions are now initially folded, except for the first few lines, and expandable on click.
Of course, as was the case before, the layout of the OPS stack trace and Java stack traces can be customized: simply edit
Another good news is that all this is now in the nightly builds, and will soon be in OPS 3.0 final as well.
Of course we welcome any suggestion as to how the current error reporting in OPS could be improved. Don't be shy!
Post a Comment