The return type of a function is an assertion. You’re saying that values of the type exist. The return value is an assertion about the arguments. You’re saying that they imply the result. The issue is that your code is incorrect, in a logic sense, if it states that for some given value the mathematical operation of division results in both an error and a number.

The issue is not one of usability or (direct) understandability, it’s an issue of correctness. Something like “well it works fine for me if I just remember to check if I receive both” or “everyone on my team understands that receiving both means an error occurred” just isn’t a valid response, it doesn’t address the problem.

Now you have 3 different states that all represent an error:

    (null, new DivideByZeroException())
    (null, null)
    (result, new DivideByZeroException())

One of which does not actually use our custom error type, and one of which contains a value for some reason. Our function is simple division! Are there really 3 different ways division can fail?

This isn't a showstopper, it's just more stuff you have to keep in your head.

> I don't see the issue?

> if we receive both, than an exception occurred and should be handled

P(decimal ∩ DivideByZeroException) = 0 , therefore we only need 2 states, not 4.