4 ms·

1. ArgumentNullException, 2. ArgumentException and 5. ArgumentOutOfRangeException shows how badly C# needs more ability to specify/enforce contracts. It's awes

by tybit 9y ago

1. ArgumentNullException, 2. ArgumentException and 5. ArgumentOutOfRangeException shows how badly C# needs more ability to specify/enforce contracts. It's awesome that C# 8 will address the number 1 problem, with non nullable references but number 2 won't be addressed until records post C# 8 by the looks of things and number 5 not until exhaustive pattern matching which doesn't look to be on the cards at all AFAIK.

matthewwarren 9y ago
Good point, yeah all the instances of 'ArgumentXXXException' points to there needing to be better language/tooling support for it.
- loarabia 9y ago
  There were the below two items [0], [1] which are runtime and tooling pieces. I've used them years ago in side projects and they were helpful but haven't kept up with them recently. They both help find or handle argument validation issues as enumerated above. [0] https://docs.microsoft.com/en-us/dotnet/framework/debug-trace-profile/code-contracts https://docs.microsoft.com/en-us/dotnet/framework/debug-trac... [1] https://www.microsoft.com/en-us/research/project/pex-and-moles-isolation-and-white-box-unit-testing-for-net/?from=https%3A%2F%2Fresearch.microsoft.com%2FPex%2F https://www.microsoft.com/en-us/research/project/pex-and-mol...
stult 9y ago
Seriously. Contracts. I inherited a relatively substantial C# WCF business line app with a large number of classes each with many nullable properties. The null handling was awful, but there were too many classes to easily refactor to apply data contract attributes across the board (at least given that I am the sole available resource to do so). Instead I tried selectively applying the null object pattern to some of the most common troublemakers. It's improved things but god I wish the original dev had used data contract attributes from the beginning. Similarly, it's staggering the number of times I've seen someone wrap their entire method (or worse yet their entire program) in empty try-catch blocks just to avoid responsibly handling null and out of range exceptions. To me, it seems like the ubiquity of this antipattern indicates that there's something inadequate about the language, tooling, or developer culture. Or some combination thereof. I'm not enough of an expert to say what the problem is or how to fix it, but in my relatively limited experience I've found requiring data contracts up front smooths over a lot of the pain points. But it comes at a cost. I've never used an equivalent in any other language, so I don't how C# and .NET compare, but it does seem like a lot of boilerplate code that can limit decoupling if misapplied.
- emodendroket 9y ago
  Well this is the problem Option classes are meant to solve but it's pretty tough to make that work without breaking all the old code where any reference value can be null

by tybit 9y ago

matthewwarren 9y ago

Good point, yeah all the instances of 'ArgumentXXXException' points to there needing to be better language/tooling support for it.

loarabia 9y ago
There were the below two items [0], [1] which are runtime and tooling pieces. I've used them years ago in side projects and they were helpful but haven't kept up with them recently. They both help find or handle argument validation issues as enumerated above. [0] https://docs.microsoft.com/en-us/dotnet/framework/debug-trace-profile/code-contracts https://docs.microsoft.com/en-us/dotnet/framework/debug-trac... [1] https://www.microsoft.com/en-us/research/project/pex-and-moles-isolation-and-white-box-unit-testing-for-net/?from=https%3A%2F%2Fresearch.microsoft.com%2FPex%2F https://www.microsoft.com/en-us/research/project/pex-and-mol...

stult 9y ago

Seriously. Contracts. I inherited a relatively substantial C# WCF business line app with a large number of classes each with many nullable properties. The null handling was awful, but there were too many classes to easily refactor to apply data contract attributes across the board (at least given that I am the sole available resource to do so). Instead I tried selectively applying the null object pattern to some of the most common troublemakers. It's improved things but god I wish the original dev had used data contract attributes from the beginning. Similarly, it's staggering the number of times I've seen someone wrap their entire method (or worse yet their entire program) in empty try-catch blocks just to avoid responsibly handling null and out of range exceptions. To me, it seems like the ubiquity of this antipattern indicates that there's something inadequate about the language, tooling, or developer culture. Or some combination thereof. I'm not enough of an expert to say what the problem is or how to fix it, but in my relatively limited experience I've found requiring data contracts up front smooths over a lot of the pain points. But it comes at a cost. I've never used an equivalent in any other language, so I don't how C# and .NET compare, but it does seem like a lot of boilerplate code that can limit decoupling if misapplied.

emodendroket 9y ago
Well this is the problem Option classes are meant to solve but it's pretty tough to make that work without breaking all the old code where any reference value can be null