RFC: Exception handling

Question

Hi there,
after playing a bit with external xml files provided by my
application i'm ready to go to the next topic on my ToDo-List.
How could one implement a good and stable technique for
exception handling? I'm talking about the interaction from spry to
our Web Framework which throws an error sometimes.
My current idea is that the server side framework could
return some kind of Error XML format which contains the exception
message and so on. This would require functions on client side to
precheck the server output.
Imho the best place for this is inside the XMLDataSet
constructor. When catching some bad XML file internal error
messages could be send using the already existing techniques OR by
providing an public function which then should be overriden by an
selfwritten one, e.g. to put it into my own `error box`.
Also, some kind of internal statemachine in XMLDataSet may
help a lot. That way each access to functions which aren't working
at the moment could be loggend and catched by an selfwritten
function.
I hope you get the idea,
what do you think?
Best regards,
Sebastian

Answer 1

Better error handling and error handling hooks is on the list
of things to do.
The way I see it, there are several types of errors that can
occur:
1. Server returns valid XML, but it's XML that describes an
error instead of the data requested.
- I believe this is what Sebastian was mentioning. I was
actually thinking of allowing a hook for developers to catch and
handle this case and perhaps leverage the states mechanism to let
them change the dynamic region markup used to display the error
since the data references in this error XML would be different.
2. The server returns an error. (Invalid URL or Server Error)
- This could be handled with states, but we need to expose
some data references, or set the data set to contain a known data
set schema that would allow the designer to show more info about
the error.
3. The server returns XML but uses a mime-type that is not
understood by Spy or the XML parsing code built-into the browser.
- I believe it was Doug [?] that had a patch that *always*
forced the data set to try and parse the XML string in the response
if the response didn't contain an XML DOM. My one paranoia about
that is that the server could actually be returning something that
is not XML, in which we would still fail and perhaps choke
somewhere else. I need to do some testing in that area.
I was thinking perhaps we should add something to the
XMLDataSet constructor that allowed a user to specify mime-types
for formats they knew were XML, but didn't use one of the standard
XML formats.
4. The browser chokes on "not-well-formed" XML.
- This is an interesting problem. IE silently fails when the
parser chokes, but Mozilla creates an XML DOM tree that reports the
error which does *not* match the XML string from the request
response. I had to add code to spry to detect when this happens.
5. An exception is thrown during Spry processing of XML data.
- This will require more programming on our part to handle
more cases.
--== Kin ==--