Use of Exceptions

Nov 20, 2008 at 9:16 PM
Hi - first off: great looking it.  I think PostSharp is one of the best tools in the Dotnet box at the moment and your use of it is really sweet. 

However, I'm not keen on throwing exceptions for validation purposes and it looks like that it the pattern you use.  Could you tell me if that is always the case or is it possible to collect the information in a validation object in any way (without throwing an exception)?


Nov 22, 2008 at 7:15 PM
Hi - thanks for your comment.

The framework does currently work by throwing exceptions but if this is not acceptable for your needs I'll definately consider making some enhancements. How would you like to see it work?

My current thinking is that if a method/parameter has a validation constraint, then the method should not execute if validation fails, and importantly, the application needs to be notified of the validation failure and that the method didn't execute. Surrounding the method call(s) in a try-catch block catching a ValidationException provides this notification with the information to log or update a UI and then decide how to continue.

I do plan on looking at how to fit PostSharp4Validation into UIs (WPF/Silverlight/ MVC) and their validation reporting facilities so developers don't need to do their own bridging. Let me know if you have any pointers.
Nov 23, 2008 at 9:42 AM
Hi Mike

I would go for the approach of having validation as an explicit action against an object and that it results in a list of validation failures - similar to the validation application block's approach.  The caller can then decide when to validatie and how to respond to the failures.  I currently use this approach in my "day job" - we have had this in place for a few years now and are happy with it's use across a number of apps.  In my "night job" I am planning to do something similar, but to have more than one type of validation failure.  This will allow me to express informational or warning responses from validation. 

The approach of firing exceptions when values are set seems more akin to code contracts, which are to be included in Dotnet 4.0.  That's not to say that having these is not valuable, I just don't see this as a validation task. 

Also, are you going to shift to PostSharp 1.5 when released and support the Compact Framework?


Nov 23, 2008 at 7:43 PM
Having object.Validate() return an object similar to ValidationResults is certainly easy to change and I can see how this is nicer to use than catching exceptions. I'll raise an issue and implement for the next release.

The approach of firing exceptions when values are set is not an object validation task but validation against business rules. I should probably make the intention clearer in the documentation. There is a little overlap with code contracts but the main difference is that validation on setting values can be configured differently depending on the deployed solution. As an example, let's say you build an Invoice Management system for two different customers, and the system uses an Invoice domain model with an InvoiceId property. For customer A, their business rules dictate that a valid InvoiceId must be an 8-digit numeric, where as customer B's business rules dictate that a valid InvoiceId is 4 digits followed by the invoice's CustomerId. In code we can declare using a validation attribute that an InvoiceId must not be null or empty - this is one of our model rules. At runtime we augment this validation with the customer's business rules validation via configuration. Using this approach we can augment domain model validation rules for different deployments. Now when the InvoiceId is set by some means (could be UI data entry) and the value does not meet business rules, a validation exception is thrown to ensure that the Invoice does not enter an invalid state.

I hope the above makes sense.

I do plane to shift to PostSharp 1.5 when released - I want to build this for Silverlight. I don't have a requirement for the Compact Framework but if it's something you want to see, please raise an issue.

Thanks for the feedback, it's very much appreciated.
Nov 24, 2008 at 3:13 PM
Hi Mike

That makes perfect sense and it's interesting to see you are using configuration to augment your rules.  Great also to hear that you are going to take a look at returning a validation object!  I'll keep an eye on the project and take a look back when you're done that.  Great also to hear you are going to shift to 1.5 when Gael releases it.  I use PostSharp to do a couple of tasks with the ORM I am currently using (XPO), some details on my blog here, here and here, if you're interested.  I'm going to shift this over to 1.5 too, but also thought I'd wait until after release.


Nov 24, 2008 at 4:17 PM
Thanks for your support Sean. I'll email once it's implemented and checked-in sometime this week for you to review. Let me know if there are any other features you'd like to see implemented. My longterm plan is to be able to declare validation on a domain model (in code or by configuration) and for that validation framework to integrate near seamlessly with UI validation systems such as MVC, Silverlight and WPF.
Dec 1, 2008 at 11:48 AM
Multi-Mode Property Validation is now supported so it is possible to switch off throwing exceptions for property validation.

Interception Validation - Validation is invoked when the property is set. If the validation fails, a validation exception will throw to ensure the model does not become invalid.
State Validation - Validation is invoked when the object is validated. If the validation fails, the validation failure is added to the ValidationResult.

These modes can be combined if required. Please see the wiki for more info.