When to return result vs throw exception?

[Hapachino]

Hey Vladimir,

Big fan and thanks for the course!

Per the title, I'm a little confused when you were returning Results versus throwing exceptions. From your previous content, I believe your stance boils down to return Results for expected errors, and throw exceptions representing programmer errors or ones that can't be handled.

Customer.promote throws when already promoted, even though this is an error we expect and can handle. Unless the programmer error is he didn't check canPromote beforehand. Similarly, the value objects used factory methods return Results with input validation, but the Customer constructor throws with invalid arguments. The implication is the programmer has to validate the name and email before calling the Customer constructor.

This feels a little inconsistent and breaks encapsulation. I wonder if you still completely agree with the code here, and if so, how you would formalize this heuristic? Should value objects comprising an entity provide input validation via Results, while entities should throw errors to protect their invariants?

Thanks again.

[vkhorikov]

Unless the programmer error is he didn't check canPromote beforehand.

Yes, that's exactly the error here, it's part of the contract the programmer violates. Take a look at this article: https://enterprisecraftsmanship.com/posts/code-contracts-vs-input-validation/
I wrote about the pattern itself here: https://enterprisecraftsmanship.com/posts/validation-and-ddd/

The same is true for the Customer constructor.