ConfigurationError handling in DEV, UAT and PROD environments should be done differently. QBO 3 has several optional web.config settings to address error handling:
For production systems, end users should never, ever, ever see a stack trace. It reveals enough information about the system to arm hackers with enough knowledge to attempt hacking the system. For DEV systems (typically local machines), full stack traces are very useful during the development cycle. For UAT systems, early testing may justify detailed errors, while later testing justifies shorter error messages (for limited client testing). OverviewError handling in QBO 3 leverages the Microsoft Enterprise Template Library's Exception Handling block, enabling web.config-driven:
Controlling what happens with a specific error depends on the exception class raised. For example, we can target different logging sinks based on:
For developers, as you code exception handling into your methods, choose carefully the type of exception you raise. Your choice will control how the exception handling can be configured. For example, if you choose to always raise a qbo.Exception.GeneralException, this will always be handled with other qbo.Exception.GeneralException errors, and cannot be targeted to a specific logging sink or suppressed. On the other hand, if you are writing a pluging for a Method Listener, you should choose to raise a qbo.Exception.ListenerException, so that all "plugin" errors can be logged to a plugin-specific log. You are welcome to create new Exception classes (typically derived from qbo.Exception.AbstractException) if you feel you have a category of errors that may need to be handled specially. On top of the exception handling block, the qbo.Application.HttpHandler will trap all errors raised from derived ashx pages, and render them via Templates/Application/Error.Select.xslt. This XSLT can be customized to mask error messages as well, and currently renders haiku because I was bored during some conference calls. Consider perusing a walkthrough of the exception handling block. Use Case: Suppress Listener ErrorsDuring unit testing on my local machine, I sometimes want to test my code while ignoring errors related to plugins. Specifically, the standard ImportForm.config file includes Method Listeners to invoke qbo2.EventHandler so custom forms can process decisions. I often don't care about processing decisions, so I have two options:
In order to test the exception handling, and to avoid changing ImportForm.config in source (as I am constantly re-deploying the DecisionWeb project), I elected for option 2. My web.config file was modified to: <exceptionHandling><exceptionPolicies><add name="StandardPolicy"><exceptionTypes><!-- This is standard --><add name="All Exceptions" type="System.Exception, mscorlib, ..." postHandlingAction="NotifyRethrow"><exceptionHandlers><add name="Logging Exception Handler" logCategory="General" type="..." eventId="100" severity="Error" title="Enterprise Library Exception Handling" formatterType="..." priority="0"/></exceptionHandlers></add><!-- This is my custom handler for ListenerExceptions --><add name="Listener Exception" type="qbo.Exception.ListenerException, qbo.Exception" postHandlingAction="None"><exceptionHandlers><add name="Logging Exception Handler" type="..." logCategory="General" eventId="100" severity="Error" title="Enterprise Library Exception Handling" formatterType="..." priority="0"/></exceptionHandlers></add></exceptionTypes></add></exceptionPolicies></exceptionHandling>Note:
RESTful Error CodesThe qbo.Exception module includes custom exceptions, and an IException interface. The IException interface allows a developer to specify a recommended HttpStatusCode when raising an exception. For example:throw new Exception.DataException("You don't have access") { StatusCode = (int)HttpStatusCode.Forbidden };will raise an exception, and cause HttpHandler to set the Context.Response.StatusCode to Forbidden (403).As you code plugins or extend QBO3, ensure client-caused exceptions throw a 4xx errors. Server-caused exceptions should throw 5xx errors. See also RESTful-friendly errors. IIS Masking all Errors as 500 - A Server Error OccurredError messages are controlled via /Templates/Application/Error.Select.xslt. If IIS is only serving up 500 - A Server Error Occurred, do the following:
Thanks to: |
Quandis Business Objects 3 > QBO 3 Blog >