Error Handling

> (a) I've been a bit annoyed at times over the past couple of weeks
> with the repeated assertions that the major implementors will ignore
> standards for error handling, so please indulge this brief outburst:
> IT'S THE MAJOR IMPLEMENTORS WHO ARE ASKING US TO DO THIS.  Got that?
> Good.

Let me see if I can put this politely: is the major implementor who 
has traditionally had the most trouble with correctness (and not 
coincidentally the largest market share) part of this group?

Anyhow, if they are all agreed that they want to be tough on errors,
why don't they just DO SO and let the editors and other tools do the
Right Thing for their customers?

> (b) You can't specify standard error recovery without ipso facto
> making the recovery behavior an implicit extension to the language.
> If an application can recover from an omitted end tag, for example,
> then you have just made omitted end tags part of the language spec.
> The HTML experience over the last few years has proven this point
> beyond any doubt (and is one of the key reasons that we are being
> asked by the Big Guys to take a hard line on error handling).

There is a big gap between specifying mandatory error recovery and 
specifying mandatory error non-recovery. In the middle is: 
"specifying/requiring error reporting and leaving error recovery
upto the best judgement of the vendor.

> (c) Some people who understand the necessity for a compiler to refuse
> to produce an executable from broken code seem to think that it's
> perfectly OK for a document processor to pass over bad spots in a
> document and carry on.  

I don't think that there is ANYBODY in this group who has made that 
argument. I may have missed it but I don't believe so. Nobody wants the
errors to be "passed over". They want them to be reported. And then they
want the vendor and user to work together to decide what is the best
thing to do from that spot.

> Maybe you have to be part of a group that
> produces support documentation for hardware and software that really,
> truly does run nuclear power stations and air traffic control systems
> to understand this, but take it from me that it is *not* acceptable
> for pieces of language to silently disappear from documents or appear
> in ways that could be misinterpreted by the user.

So what? If you are running a nuclear power station or air traffic 
control system you choose the app that gives you the rigorous performance
you need. That's called market differentiation. Some people need C++
compilers that can guarantee real-time dyanmic memory allocation but you
don't see that in the C++ standard!!!

Now supposed this draconian bit gets into the XML standard can you now say: 
"It's now safe to run my power plant with a random browser downloaded off
of the net?" HELL NO! You're not even close. Well-formed-ness is so low down
on the error checking totem pole that we've already wasted more time arguing
about it than it is worth! Well-formedness is absolutely USELESS in any
mission critical application. So this requirement doesn't bring you any 
closer to your goal. You must STILL talk to the vendors to see what they do
about broken links, bad attributes, invalid content models, etc.

I haven't yet seen anybody dispute this but I keep hearing about medical 
records, financial records, nuclear plants and cruise missiles. They just
aren't relevant.

> People who insist that there is a customer requirement for "forgiving"
> document applications overlook the fact that we already have those:
> they are called HTML browsers.  

And SGML editors. Doesn't every SGML editor you have ever used do its best
with incorrect data? How about Jade? Right this very minute I am processing
invalid and non-well-formed documents with it. It works great. It saves me 
*hours* of work dummying links, making wrappers etc. People have different
needs and these draconian rules are trampling all over mine.

 Paul Prescod

Received on Tuesday, 6 May 1997 18:47:02 UTC