Changes to the Exception Handling Application Block

The following changes have been made to this version of the Exception Handling Application Block:

• Changed : When building a LoggingExceptionHandler, instead of creating a logging stack every time and ignoring it if the value for the use the default logger flag on the handler is set to true, the build process now uses the value for the flag in the configuration file to create the handler with either Logging.Writer (if true) or the result of creating a new stack (if false). The handler now only knows it has a writer; it does not know where it came from.
• Fixed : The DesignTime nodes for ExceptionHandlers are now handled correctly when using template-based messages. The variables are now accessed correctly when mapping an exception handler configuration object to the corresponding node and a valid configuration is saved.
• Fixed : Invalid XML generated by the XmlExceptionFormatter is fixed. Exception formatters now must include the HandlingInstanceId (which is generated on each exception handling request). The way the exception formatter includes HandlingInstanceId depends on the individual formatter. The XmlExceptionFormatter adds it as an attribute of the top-level Exception element; the TextFormatter adds it as the first line of text. An ID equal to Guid.Empty can be ignored.

  The logging exception handler no longer adds the exception handling ID to the message to log. The formatter handles the ID. Exception Formatter types used with the logging exception handler must now implement a constructor with the parameters TextWriter, Exception, and Guid.

  There is no backward compatibility support. Creators of custom formatters must update the formatters to be used with this version so that the handling instance ID is not lost because a formatter does not support it.