Care to post an example (or a link to one) of how you use your OperationResult and how it allows you to compose operations much better?

I’m pretty leery of 3rd party frameworks that don’t tell me what exceptions they throw, and if I have to use one that doesn’t divulge that information, I’ll wrap its API to exert some control over what the rest of my application has to deal with.

If I or my team wrote the framework (which is usually the case for the application domain model), we know what exceptions we’re going to get.

Pssh!!! What do those guys know.

I like an “OperationResult” object, with Success and Errors as attributes. It lets me compose operations much better, and I don’t have to resort to an IsValid.

Exceptions are annoying as control flow logic simply because they are neither obvious nor discoverable as users of a framework or API. If something fails and I need to take action, tell me directly. There is nothing in C# that allows me to know what exceptions “might” get thrown, so I can handle them appropriately.

I think the idea that exceptions should be reserved for “exceptional” circumstances is a vestige of the original guidance for using exceptions in C++ (as is the notion that using exceptions incurs a large performance penalty). I believe that even in the C++ world, that guidance is no longer as absolute as it once was.

@bogardj

Actually, using exceptions to separate the concerns of error handling and main logic flow is a very good choice. For a nice exposition on that take a look at Robert Martin’s Clean Code and the section on Error Handling that Michael Feathers wrote.

Additionally, many would consider the use of an IsValid method on domain objects to be a poor practice. The argument here is that domain objects should not be allowed to have an invalid state (i.e., have their invarients violated) at any point in time.

It’s just that exceptions as _control flow_ logic are a very poor choice. It’s like the old On Error Resume Next in VB6. There are easier ways to indicate that an operation failed, and provide better options for consumers of APIs, than throwing an exception.

I have done exactly that and found that performance is absolutely fine. Did you? As long as you don’t have a debugger attached, you can easily accommodate 10,000 – 100,000 exceptions per second, so setting up some logic that is likely to cause at most a few exceptions per second in total can’t be rejected on performance grounds.

@various commenters
Who came up with the idea that exceptions should be reserved for “exceptional” circumstances, and what is exceptional anyway? The .NET framework class libraries establish a clear pattern for the semantics of an exception. In .NET, an exception means “this method could not complete the operation that its name describes” and that is why they’re always used to signal an incomplete or failed operation (and why we don’t use Win32-style return codes).

I’m not saying that IDataErrorInfo is great (I would certainly change it in a couple of ways if I had the chance) but rather trying to understand why people don’t want to use exceptions even for scenarios that match their intended use.

Also, it is possible to use the IDataErrorInfo without using UpdateModel and having it throw an exception. I am using parameter bound models as in your second example with IDataErrorInfo and it doesn’t throw an exception on me if there are errors. It simply sets ModelState.IsValid to false.

So if you have 100,000 users all submitting invalid forms and this performance would be an issue ??

I’ve maintained large amounts of exception based programming code and it’s not pretty when you’re throwing exceptions all over the place to control flow.