IT:AD:Design:FAQ

• Should Exceptions be used for Validation purposes (ie Flow Control)?

The answer ('no') is more clearly understood considering several issues:

• The standard mantra of Exceptions, is to reserve them for Exceptional circumstances. Business or Technical Validation is not an exception if it is happening every 2 seconds.
  • But it's a recommendation. In some languages (oCaml) exceptions are lightweight, generate no stack, and it is acceptable to use them in some circumstances.
• Using Exceptions for Flow Control in .NET is expensive (2500 times slower).
  • Ref: http://stackoverflow.com/a/1282577
• Using Exceptions makes code debugging harder to distinguish between 'legitimate' validation exceptions and unexpected exceptions (eg: Sql exception versus a validation error). A common side effect is that with debugging settings set to catch all exceptions is too much, and when set to catch only unexepected exception there is a loss of visibility of what is actually going on.
• There's a post by the guy who actually wrote the exception handling part of the network. He recommends not using them for that purpose.
  • Ref: http://stackoverflow.com/a/162027
• When throwing an exception, you can only return one error message, showing them to the end user until all conditions are met. A better alternative would be to collect together n validation error messages, and show them to the user in one go.
  • Ref: http://stackoverflow.com/a/1504334
• There are other issues at stake too. For two reasons (a: Exception stacks are tightly tied to a specific process's memory space, and b: because SOAP, on which WCF is built, is not a .NET specific architecture), Exceptions are not serializable across the wire between Tiers in an N-Tier application. That makes using Exception for routing purposes difficult to implement. A better solution in such cases is the use of an XAct.IResponse object that has a Message array (and a Success bool flag to indicate that non of the Message objects have a Severity of Error or BlockingWarning.

• What portable Exceptions can we use to manage security?

I agree whole heartedly that the available System Exceptions are thin on the ground.

• Authentication: Use System.AuthenticationException when login fails.
• Authorization: this one's really hard to decide on for sure.
  • You can role your own “App.AuthenticationException”, but that causes a dependency
    • Note that there is one in defined in XAct.Core
  • InvalidCredentialException: “The exception that is thrown when authentication fails for an authentication stream and cannot be retried.”
  • SecurityException: “The exception that is thrown when a security error is detected.”
  • UnauthorizedAccessException: “The exception that is thrown when the operating system denies access because of an I/O error or a specific type of security error.”

Of the above miserable list of choices, using XAct.Core's XAct.AuthenticationException seems to be the least ambiguous. But I'm biased of course. Otherwise, consider InvalidCredentialException.