E
Ed Kramer
I thought this might be useful for someone...
I was doing a little work earlier using an Xmldocument class to create &
maintain a minor store of data in Xml format.
I'd gotten the whole thing up and going and I decided to start testing
'disaster' scenarios.
For example, you start up but your file has been deleted, or you try to save
and the file is read only. Or you lack write permissions. Or you try to load
and the document is empty. Or the XML inside the document is malformed
because someone edited it manually.
I noticed that on the call to the XmlDocument's .Load(<stream>) method if
the document was empty it would throw an XmlException.
Unfortunately unlike much of the structured exception handling in .Net
that's a generic exception for a lot of different types of events. Other than
the LineNumber , LinePosition and Message properties, you're not really
getting much information there to uniquely identify specific Xml based
exceptions. In my case, I was getting an XmlException with a message of "Root
element is missing.". Yeah that tells me as the developer, but how do I
handle it other than catching XmlException. Catching generic exceptions is
bad practice.
In my case, if document.Load( ) failed that was ok. Because later in that
same method I'm actually setting up the document properly anyway before I
call .Save(). But, if I put a try/catch around .Load( ) and catch
XmlException, I would be catching everything related to XML coming out of
that call. Whether it be the root element missing or someone forgot a '>' on
line 182 column 12. I'd want to catch the former and allow the latter to go
right on by. Don't want to swallow all exceptions, after all. You can't try
to determine the type of exception based on the message, because that message
could be language dependent. What if I run it on a Cyrillic machine. Trying
to match "Root element is missing" in English against say Spanish isn't going
to match.
Looking over the XmlException object, I noticed it had a HRESULT property on
it in my watch window. That's great! I thought. I can uniquely identify this
exception and handle that case. Unfortunately the HResult property is a
protected member of the class. So, I couldn't grab hold if it directly to
even put it in a Switch to do something slightly more structured.
I also tried to use reflection to get that property's value, but that didn't
work well.
Then it occurred to me. It's a Protected method. So all I need to do is
derive a class from XmlException and that will give me access to the
property. I can then use that to identify the specific exception.
I then created a NeoXmlException class as a new base and created a
XmlRootElementMissingException that derived from it. I put a try/catch around
my call to document.Load( ), catching the generic XmlException. I then pass
that exception to an intermediary factory style class which if it wraps a
NeoXmlException around it, giving access to the protected HRESULT property.
If the factory can identify the type of specific XML exception it wraps one
of those specific classes around it and throws it. It it can't, it just
rethrows the original exception. As it stands right now I only have the
XmlRootElementMissingException class and everything else goes through like a
18-wheeler through a sedan. But as I find more errors that need this
treatment it's easy enough to add another class inheriting from XmlException
and add it to the factory.
I don't really understand why MS didn't either make separate exceptions in
the first place or give public access to HRESULT so we can do it ourselves.
Almost everything throws very specific exceptions which you can catch and
most books I've read say that catching generic exceptions ( the Exception
base class for example ) are very bad practice.
I just thought I'd post it here since it seems like a useful (if convoluted)
solution to this problem. Of course if anyone has a better idea lemme know so
I can revise my XML IO classes.
I was doing a little work earlier using an Xmldocument class to create &
maintain a minor store of data in Xml format.
I'd gotten the whole thing up and going and I decided to start testing
'disaster' scenarios.
For example, you start up but your file has been deleted, or you try to save
and the file is read only. Or you lack write permissions. Or you try to load
and the document is empty. Or the XML inside the document is malformed
because someone edited it manually.
I noticed that on the call to the XmlDocument's .Load(<stream>) method if
the document was empty it would throw an XmlException.
Unfortunately unlike much of the structured exception handling in .Net
that's a generic exception for a lot of different types of events. Other than
the LineNumber , LinePosition and Message properties, you're not really
getting much information there to uniquely identify specific Xml based
exceptions. In my case, I was getting an XmlException with a message of "Root
element is missing.". Yeah that tells me as the developer, but how do I
handle it other than catching XmlException. Catching generic exceptions is
bad practice.
In my case, if document.Load( ) failed that was ok. Because later in that
same method I'm actually setting up the document properly anyway before I
call .Save(). But, if I put a try/catch around .Load( ) and catch
XmlException, I would be catching everything related to XML coming out of
that call. Whether it be the root element missing or someone forgot a '>' on
line 182 column 12. I'd want to catch the former and allow the latter to go
right on by. Don't want to swallow all exceptions, after all. You can't try
to determine the type of exception based on the message, because that message
could be language dependent. What if I run it on a Cyrillic machine. Trying
to match "Root element is missing" in English against say Spanish isn't going
to match.
Looking over the XmlException object, I noticed it had a HRESULT property on
it in my watch window. That's great! I thought. I can uniquely identify this
exception and handle that case. Unfortunately the HResult property is a
protected member of the class. So, I couldn't grab hold if it directly to
even put it in a Switch to do something slightly more structured.
I also tried to use reflection to get that property's value, but that didn't
work well.
Then it occurred to me. It's a Protected method. So all I need to do is
derive a class from XmlException and that will give me access to the
property. I can then use that to identify the specific exception.
I then created a NeoXmlException class as a new base and created a
XmlRootElementMissingException that derived from it. I put a try/catch around
my call to document.Load( ), catching the generic XmlException. I then pass
that exception to an intermediary factory style class which if it wraps a
NeoXmlException around it, giving access to the protected HRESULT property.
If the factory can identify the type of specific XML exception it wraps one
of those specific classes around it and throws it. It it can't, it just
rethrows the original exception. As it stands right now I only have the
XmlRootElementMissingException class and everything else goes through like a
18-wheeler through a sedan. But as I find more errors that need this
treatment it's easy enough to add another class inheriting from XmlException
and add it to the factory.
I don't really understand why MS didn't either make separate exceptions in
the first place or give public access to HRESULT so we can do it ourselves.
Almost everything throws very specific exceptions which you can catch and
most books I've read say that catching generic exceptions ( the Exception
base class for example ) are very bad practice.
I just thought I'd post it here since it seems like a useful (if convoluted)
solution to this problem. Of course if anyone has a better idea lemme know so
I can revise my XML IO classes.