First off, there's Tapestry's default exception report page. When an exception is thrown during a request, most often a coding error in a Tapestry page or template, Tapestry moves heaven and earth to report the exception properly. For example, in Tapestry it is not allowed for a component sub-class to define a parameter with the same name as a parameter from a base class, as this creates an ambiguity. When this situation occurs, an exception is thrown from deep in the bowels of Tapestry:
That's a start, but it's not great feedback; you'll be doing a lot of work to figure out what was going on in Tapestry leading up to the exception, and from there, figuring out how to fix it; there's lots and lots of noise in the repeated stack traces (caused by nested exceptions). However, you can see a glimmer of hope in those first few lines, the ones that start
Registry [ 1],
Registry [ 2], ...
Tapestry goes to a lot of trouble to track what is going on during the handling of a request; it keeps a stack of operations which describe what Tapestry is doing at any particular time. There's still a lot of internal details, but the gist of it is that Tapestry needed to create an instance of the ParameterConflictDemo page, and hit an error while doing something with the ParameterSubClass component (sorry for the ugly names, I'm using examples from Tapestry's internal test suite).
However, parsing apart the console output is NOT what a Tapestry developer does; instead they'll get all those details, and more, from the Tapestry exception report page:
The frame in bold blue? That's a frame in the application's package, rather than code in inside Tapestry. That highlighting is very useful for letting the developer quickly figure out if the cause of the exception is a minor problem inside their code, or something more involved that shows up inside the Tapestry framework code.
Scrolling further down, we start seeing even more relevant information: all the details of the incoming request:
you don't have to show all that to your end users). More than that, there's attention to detail throughout Tapestry to provide real exception messages. For example, if you provide a component type name that doesn't match some component, Tapestry responds with a detailed message, including a list of all the known component types:
Again, Tapestry doesn't want you to have to put on your detective's hat to figure out what's wrong and how to fix it. It's providing all the details you need right when you need them.
Live Application Introspection
What if your problems are more subtle? How do you track down other issues, like performance problems or memory utilization? Well, Tapestry provides some introspection to address those questions as well. Tapestry 5.3 adds the Page Catalog, a special page for providing information about what pages have been loaded into memory, and a few details about how big they are, and how long they took to assemble:
And what if you are tracking down something even more subtle? Well, by enabling some logging, Tapestry will output that operations trace as each operation starts and finishes. It's an avalance of information, much of it about instantiating services ... below is a log of just what happens when you first startup a Tapestry application, before it even processes it's first request:
Because Tapestry operates lazily, instantiating pages and services only as needed, even more happens when the first page request arrives: