Why the heavy dependency on throwing Exceptions?

Why the heavy dependency on throwing Exceptions?

Old forum URL: forums.lhotka.net/forums/t/7445.aspx


McKay posted on Wednesday, August 12, 2009

Why is it that so much of the CSLA code relies on Exceptions being thrown when determining the outcome of relatively rudimentary checks? For example. Throw Security Exception when user not authorized. Throw exception if can’t execute command. I thought exceptions should be the exception and shouldn’t be used to control logic.
There must be a better way to return the results from the business object to the user without relying on Exceptions.
It just doesn’t feel right!

tmg4340 replied on Wednesday, August 12, 2009

Some exceptions are thrown because that's what the .NET infrastructure is expecting, so CSLA has to comply.  In other instances (for example, your security exception), if your application gets to that point, you very likely have a problem with your code.  An exception can be the best way to bring that to the fore, because they are much harder to ignore (unlike a return code that indicates an error, which is discouraged in .NET coding practices anyway.)  I don't consider these situations "logic control exceptions" - they truly are an exceptional situation.

HTH

- Scottt

cmellon replied on Thursday, August 13, 2009

I think the security exception is the correct approach, as I would have thought that the UI would disable the delete button for example if the user is not authorised.

If the user managed to run the delete command because the UI didn't disable the button for any reason then an exception would be thrown.

ajj3085 replied on Thursday, August 13, 2009

Well, regarding security exceptions.. would you rather not know why you're not seeing the value on your from, or worse, can't figure out why the property isn't being set?

The assumption is that you as the UI developer will properly disable UI elements if you're not allowed to write to a property (you can call CanWriteProperty, use ReadWriteAuth component, etc). You should also note that getting a property to which you don't have access by default returns some kind of empty value, at least for strings.

An exception should be thrown whenever the method called cannot fulfill its part of the design contract, for any reason. So if a command throws an exception, its because it can't fulfil its contract, even if that reason is say security, which you should have checked prior to allowing the method to be called. If you execute a command and don't have permission, returning nothing or returning a default value isn't great... because you would intereperate that as the valid result of the command.

So its not controlling logic with exceptions, its alerting you to the fact that the API contract cannot be fulfill properly. Does that make sense?

McKay replied on Thursday, August 13, 2009

Much clearer now thanks. Almost all of the examples I see are examples of the business object doing the checks and there have never been any clues that the UI is the first line of defence. I see that the business objects exceptions are a sort of last resort kind of thing.

RockfordLhotka replied on Thursday, August 13, 2009

You should read through Chapters 19 and 20, which discuss WPF and Web Forms interfaces, as they discuss how the UI is responsible for providing visual cues to the user.

CSLA includes controls to help automate this for Windows Forms, WPF and Silverlight.

rsbaker0 replied on Friday, August 14, 2009

I'll wade in just to offer that the alternative to exceptions (in general) is to introduce a requirement that the caller test the results of an operation.

For many operations, this is impractical, and failure to check the result of a failed operation where it is practical can result in very subtle and hard to find bugs.

Exceptions, on the other hand, can't easily be missed, and they allow you to write code that can "assume" success, because otherwise an exception will occur and the process is guaranteed to short circuit (unless you explicitly program around the exception)

We have central exception handling and simply display the error to the user, and otherwise rarely explicitly handle individual exceptions. It seems to work very well.

Copyright (c) Marimer LLC