> > 3) Create a set of exception classes. > > Extensions should have an architected error reporting mechanism, which > might include warnings and non-fatal errors. But if someone isses a fatal > error or throws an exception, I'd suggest that we should _not_ attempt to > proceed past it.
If a base exception class is created and if the extension throws either the base class or a derived class, then processing may or may not continue (defined as an attribute of the exception) . If a completely different exception is thrown then processing definitely stops. What you are defining here is the structure returned when an extension wants to report an error. As people build extensions, recoverable error handling will be required and it would be nice if a common error handling mechanism was defined. This allows a single template to be defined that would report at least the basic error information. What I was working with before was: apply-templates select=$var/ext-error would trigger error handling then in the template, the xpath statement /ext-error/message would provide the basic message no matter what extension function was called. The old way, only one of the apply-template calls would succeed. <xsl:variable name="table" select='sql:query($db, $query)'/> <xsl:apply-templates select="$table/sql/metadata/column-header"> <xsl:apply-templates select="$table/ext-error"> The new way <xsl:variable name="table" select='sql:query($db, $query)'/> <xsl:if test="not($table)" > <xsl:message>Error in Query</xsl:message> <xsl:copy-of select="sql:getError($db)/ext-error" /> </xsl:if> <xsl:apply-templates select="$table/sql/metadata/column-header"> The problem I ran into was that the second apply-tempalte call was doubling my transformation time in a stylesheet that consisted of primarily SQL calls. So then I moved to the null document and using the xsl:if statement.
