Currently CSLA defines its own ValidationException class. Why can't it just use ValidationException defined in DataAnnotations' namespace?
CSLA has existed for just a little longer than DataAnnotations (more than a decade longer actually). It had to do something for all those years before Microsoft finally realized that validation was important 
Switching exception types is a breaking change. People use exception types in their catch blocks. So switching to use a new type of exception isn't the trivial thing it might seem at first glance, since it means that the thousands of CSLA users would have to go through their code to find and fix all those catch blocks.
That said, this didn't occur to me and would be a good idea for CSLA 4 - I'll have to see if I can squeeze this in - though technically the door has closed for adding new CSLA 4 changes.
Thanks for bringing this up!
I've put a little more thought into this. I'm not entirely sure it is a good idea.
There's a short-term pain issue - it is another breaking change from 3.x to 4 - but I could live with doing that.
The bigger problem is that it forces a dependency on System.ComponentModel.DataAnnotations for anyone using Csla.dll.
Right now, even in CSLA 4, you don't need to add a reference to DataAnnotations unless you decide to actually use the attributes it contains. It is completely optional.
But if I start raising ValidationException exceptions from DataAnnotations then anyone handling that exception type (which I suspect is most people) would need to reference DataAnnotations in their projects.
What does everyone think? Should I make this change? Do you explicitly handle ValidationException exceptions in your code?
I do not like the additional dependency. As I recall there was a huge backlash about this type of dependency in earlier work you did. For that reason alone I would not make the change. If DataAnnotation exception was in a standard .Net .dll that is always referenced anyway then I would be for it.
Joe
No advantage I can see.
I think Csla should just keep its own exception. MS may take theirs in another direction at some point, plus why add a dependency for a single class that provides no other advantages?
Copyright (c) Marimer LLC