MVC DDD and throw errors for business logic

I read professional asp.net design templates for a book from scott millett, and in his example he checks his business logic in the Validate () method, and if any violated rules are violated, they are added to the collection and service level calls by model method GetBrokenRules ().

Now I have also read several books, blogs, and forums about DDD, and it says that in DDD an object should never end up in an invalid state.

All the examples that I saw regarding DDD throw errors when a business rule was violated, instead of returning a collection of violated rules. I even downloaded the latest scott millett source code, and now it has changed its code, which now throws errors, rather than passing a list of broken rules. I also saw the same approach with other sample DDD code.

I have a debate with a team member who believes that throwing errors are expensive resources, and we should NOT issue an error, but return a collection of broken rules, as we currently have. However, by doing this, we bypass the object, which is invalid because it has quirky data, and we only check its violated rules at the end.

I just thought about what other people think about this. Should we make a mistake as soon as the business rule ends? If so, can you highlight any of the pros and cons of this. I don’t know how resource expensive throwing errors are in .net, so I cannot object to this point, but I was wondering if this is also a matter of personal opionin instead of coding standards.

Mike