I've been using a try/catch statement to run through whether or not an element exists when I parse through it. Obviously this isn't the best way of doing it. I've been using LINQ (lambda expressions) for the majority of my parsing, but I just don't know how to detect if an element is there or not.
One big problem with some solutions I found is that they take 3-4 times more code than using the try/catch block, which kind of defeats the purpose.
I would assume the code would look something like this:
if(document.Element("myElement").Exists())
{
var myValue = d开发者_C百科ocument.Element("myElement").Value;
}
I did find this link, but the looping is unecessary in my case as I can guarantee that it will only show up once if it exists. Plus the fact of having to create a dummy element which seems unecessary as well. Doesn't seem like it's the best way (or a good way) of checking. Any ideas?
XElement e = document.Element("myElement");
if (e != null)
{
var myValue = e.Value;
}
http://msdn.microsoft.com/en-us/library/system.xml.linq.xcontainer.element.aspx
"Gets the first (in document order) child element with the specified XName."
"Returns Nothing if there is no element with the specified name."
Any() is the Linq command.
Assert.IsFalse( new [] { 1, 2, 3, 4 }.Any( i => i == 5 ));
Btw, the comment above about "try / catch" can be true, but isn't in almost all cases. It depends on how you build your solution. In your Release build, turn off as much flags as possible that smell like "Debug" even from a distance. The less the runtime has been told to memorize stack traces and stuff during building, the faster "try / catch" becomes.
Btw, #2: The famous architectural patterns "Tell, don't ask!" (TDA) and the "Open Close Principle" (OCP) forbid the usage of such infamous code like "if (!(fp = fopen(...))". They don't just encourage you to use "try / catch" but force you to do so. Because the OCP not only demands to obey within your own code but also when calling foreign stuff (i.e. libraries like stdio).
Why OCP, not TDA in the last sentence? Because you're not allowed to widen the meaning of existing code. Sticking to the simple "fopen" example, what are you going to do when the result is Zero? Why exactly did "fopen" fail? You could check wether there's enough empty space left, or if the file system is writeable. Of if the file name is valid. Or whatnot. Still, your goal cannot be achieved: open the file. Imagine a headless application, so no intervention of the user is possible. Now what? There is exactly no reason to further fumble with the stuff, because "fopen" failed. You'll need a fallback strategy. Dot. If "fopen" has failed, it has failed.
Rule of thumb: Think of your code as always succeeding (KIS). If your code willingly may 'fail' in terms of that a result set regularly may contain elements or not, put the logic into the class. Perhaps you have to distribute data, properties, and questions, and methods across different classes (TDA). Perhaps you have to readjust your code according to SLA.
In your case, though, make sure the element is existing. If you cannot, it's not your fault. Deep down in your code (a wrapper where all the mistakes of former coders get beautified), transform the data needed into another entity such that further up there is no need to "if".
Any()
is the simplest way to check if an element exists.
If you have to make sure that the element is unique, you'll have to do something like .Count() == 1
. Alternatively you could implement your own extension method, but this would be only a wrapper around .Count == 1
.
精彩评论