Note that there are some explanatory texts on larger screens.

plurals
  1. POWhy do the nullable explicit cast LINQ operators throw invalid format exceptions on empty values?
    text
    copied!<p>First off, I know this question can be answered with a simple response that an empty string is not a null value. In addition, I only recently discovered the cast operators earlier in the year via another stackoverflow question and don't have a ton of experience with them. Even still, the reason why it's not entirely that simple is these cast operators when combined with the null coalescing operator, are billed as an elegant solution to dealing with error conditions like missing elements or attributes in LINQ expressions. I started using <a href="http://www.hanselman.com/blog/ImprovingLINQCodeSmellWithExplicitAndImplicitConversionOperators.aspx" rel="nofollow">the approach described by ScottH in "Improving LINQ Code Smell..."</a> and by ScottGu <a href="http://weblogs.asp.net/scottgu/archive/2007/09/20/the-new-c-null-coalescing-operator-and-using-it-with-linq.aspx" rel="nofollow">"Null coalescing operator (and using it with LINQ)"</a> as a way to guard against invalid/missing data in a concise and semi-elegant fashion. From what I can gather that seems to be one of the motivations for putting all the cast overloads in the LINQ classes in the first place.</p> <p>So, in my mind the use case of dealing with a missing value isn't all that different than dealing with an empty one and in the linked articles, this approach is billed as a good way to go about dealing with such situations.</p> <p>Scenario:</p> <pre><code>int length = (int?)elem.Attribute("Length") ?? 0; </code></pre> <p>If the @Length attribute is missing, the cast results in a null value and the ?? operator returns 0;</p> <p>If the @Length attribute exists but is empty the cast internally branches on int.tryparse and throws a format exception. Of course for my usage, I wish it wouldn't and would simply return null so I could continue using this approach in my already somewhat convoluted LINQ code.</p> <p>Ultimately it's not so much that I can't come up with a solution but more so that I'm interested to hear if there's an obvious approach that I've missed or if it anyone has a good perspective on why the missing value scenario was addressed but empty value scenario was not.</p> <p><strong>Edit</strong></p> <p>It seems there's a few key points I should try and highlight:</p> <ul> <li><p>The linked articles are from MS staff that I admire and look to for guidance. These articles seem to propose (or at least call attention to) an improved/alternate approach for dealing with optional values</p></li> <li><p>In my case optional values sometimes come in the form of <em>missing</em> elements or attributes but <strong>also</strong> come in the form of <em>empty</em> elements or values</p></li> <li><p>The described approach works as expected for missing values but fails for empty values</p></li> <li><p>Code that follows the described approach appears to be guarding against the lack of optional values but in fact is fragile and breaks in a particular case. It's the appearance of protection when in fact you're still at risk that concerns me</p></li> <li><p>This can be highlighted by stating that both linked examples fail with a runtime exception if the target element exists but is empty</p></li> <li><p>Finally, it seems the key takeaway is the described approach works great when you have a contract in place (possibly via schema) which ensures the element or attribute will <strong>never</strong> be empty but in cases where that contract does not exist, this approach is invalid and an alternate is needed</p></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload