One of the most frustrating things about
working on software is that programmers tend to
treat guidelines and best practices as if they were
written in stone and handed down by a diety from
above. In the .NET Framework developers are
encouraged to use exceptions for signalling errors
while error codes are frowned upon. On the surface,
it sounds like a great idea to get rid of error
codes until you create an application or API where
lots of different errors could occur. For example,
if you are writing an XML parser
or a W3C
XML Schema validator then avoiding error codes
makes it difficult for users of your API to target
certain classes of exceptions.
Last night I fixed a bug in RSS Bandit that had to
do with invalid characters in XML feeds where I
realized the only way to tell that such an
exception had been thrown by the application was to
write
if((e is XmlException) &&
(e.Message.IndexOf("invalid character")!=
-1)){
msg = e.Message.Substring(5);
}
the above is dumb code. The fact that it is hard
to internationalize is quite a problem and one that
wouldn't exist if the XmlException class had an
error code. Chalk up another one to religious
adherrence to software design guidelines.
More below on iPod annoyances, quirky behavior in
Soul Calibur 2 on XBox, slashbots on XML in
Microsoft Office, and RSS Bandit on MSDN again and
a bunch of other random stuff.