Suggestions for central handling of ValidationExceptions?

Suggestions for central handling of ValidationExceptions?

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


rsbaker0 posted on Friday, April 03, 2009

So far, we have been designing along the lines of making our application as "exception friendly" as possible. So usually all exceptions are rethrown after doing any cleanup that might be required.

The application has registered exception handlers to catch the ones that we let percolate to the top, which is almost all of them. This lets us do logging, decide how to present the error to the user, etc.

However, ValidationException objects seem to be problematic. They have no details at all except for "Object is invalid and can't be saved", which doesn't specifically tell the user what is wrong. Also, the object context in which the exception was thrown doesn't seem to be available (in contrast with the DataPortalException, which includes the object that caused the problem).

So, I can't implement centralized exception management with the ValidationException as is.

How are others dealing with this? I'm experimenting with a derived class modeled after the DataPortalException that includes (1) the broken object and (2) whose message is the BrokenRulesCollection.ToString(), but I'm not sure whether this is a wise approach.

ajj3085 replied on Friday, April 03, 2009

I don't allow users to get to this point usually.  If somehow they can click save, I check IsValid and use BrokenRulesCollection to communicate problems.

I think that's part of your issue; exceptions should be for the truly exceptional.  An object being invalid is a common and normal occurrence, so you shouldn't be using exceptions to let the user know... you should be checking before hand.  Don't use exceptions as control logic.

rsbaker0 replied on Friday, April 03, 2009

I don't disagree, and I'm certainly not using the exceptions as logic. 

I see it as a support problem as much as anything. Sure, you can catch each of these situations on a case by case basis (disable buttons, or specifically check validity and display error before hand, but how do you handle the missed case? We probably have 50-100 situations or more that require "saving" of some sort, and programmers being what they are, some are definitely not going to be caught until later. We find that the Toolbar icons in the framework we are using aren't bindable, so disabling the "Save" button requires specific code in each case.  

Our application handles it fairly gracefully -- the absolute worst case seems to be that you have to close and reopen the screen that you are on.  But the error that ends up being displayed when this happens doesn't tell the user what they did wrong.

I'd be much happier if the the ValidationException just had the first broken message whose severity was "Error" as it's error message for cases when the object was broken (or at least included this as a member you could get to).

Copyright (c) Marimer LLC