74 likes
·
10.0K reads
8 comments
How do I as a user of this interface/signature know that there are more expressive sub types? Because all I see is the base class, and there is little if anything that tells me there is more.
Actually something I experienced with the new Eventuous library for even sourcing, something failed, but I never new because nothing was thrown, hence nothing was logged.
Maybe a property less base type would help? No information available would be a hint to look for more. A Match(…) method taking lambdas for all variations would be better, but requires more work.
Too bad sum types are not here yet in C#.
This is absolutely an issue I have ran into due to C# lacking discriminated unions, though the OneOf library is pretty good in place of them.
I think in this case you'd have to actually look at the code emitting the results, so I tend to restrict this to the domain layer. I suppose you could also add XML comments to your public method detailing the various result types, though comments are only useful if they are up-to-date.
Thanks for the write-up! I really see the value of this pattern, as I often encounter the boolean return type being used. I will definitely keep this pattern in mind as a possible refactoring.
Thank you! I've used this pattern recently on a big refactor at work and it's been a huge help.
Great article. This technique is really nice for writing functional programming style code
Thank you 🙂 I actually got the idea from F#
I was just talking about this pattern at work today. I made a point about speed against exceptions, because throwing exception can be quite costly against newing up class instance of the result. Also with a result, the method has actually well defined interface of what it returns instead of returning various exceptions that are not visible anywhere from the outside when <summary>...<exception> is not defined. I couldn't persuade him. He didn't believe in my arguments. So I told him that I will try to benchmark newing vs throwing. Maybe that will persuade him. However having well defined outputs is more important for me. Because now we have wcf service that is throwing on every failure, but sometimes client doesn't catches the errors. How could it, when it doesn't know what all to catch :D
Really like this pattern! It actually fits one of my projects, will try to implement it next week. Another point that I think is against throwing exceptions is that your code should throw exceptions only in exceptional scenarios. The above examples (fradaulent activity, not enough funds, etc) are not exceptional scenarios.