|Error handling with Coco/r email@example.com (John Williams) (2008-12-07)|
|Re: Error handling with Coco/r firstname.lastname@example.org (Glen Herrmannsfeldt) (2008-12-06)|
|Re: Error handling with Coco/r DrDiettrich1@aol.com (Hans-Peter Diettrich) (2008-12-07)|
|Re: Error handling with Coco/r email@example.com (Glen Herrmannsfeldt) (2008-12-07)|
|Re: Error handling with Coco/r firstname.lastname@example.org (email@example.com) (2008-12-13)|
|From:||Glen Herrmannsfeldt <firstname.lastname@example.org>|
|Date:||Sun, 07 Dec 2008 22:19:44 -0700|
|Organization:||Aioe.org NNTP Server|
|Posted-Date:||08 Dec 2008 05:46:07 EST|
Glen Herrmannsfeldt wrote:
(snip on compilers and error messages)
> [Back in the 1970s there was a lot of work on automatic error correction,
> which was of some interest when compilers ran as batch jobs and you wanted
> to get as much out of each job as possible. I agree that these days once
> you've pointed out where the error was, there's little point in doing any
> more work. -John]
I remember some of the ones that the PL/I (F) compiler used to
give me, sometimes good sometimes no so good.
There are many times when one small error can result in a very
large number of messages. In those cases, it might be better for
the compiler to 'correct' the error and then continue.
One that seems obvious is that a mistake in one part of a declaration
statement often causes the whole statement to be ignored, resulting in
messages related to all the other variables. In cases like that,
a little fixup goes a long way.
There are some cases where the wrong message can be very confusing.
Not so long ago in comp.lang.fortran there was a question about an
error message related to a statement function being before executable
statements. The real error was related to a mistake in an array,
declaration. Figuring out the most likely message might not only
depend on the number of changes, but also the likelihood of using
Return to the
Search the comp.compilers archives again.