Re: Error handling.

[hendrik@topoi.cam.org (Hendrik Boom)]

> Hendrik Boom wrote:
> 
> > My experience -- with many compilers over many decades -- is that this
> > is not a good idea.  It is best to write out messages as soon as errors
> > are detected, and flush the buffer after each one.  Many Many times
> > I've had a compiler crash for one reason or another (parhaps because of
> > an inconsistent state caused by the very error it detected)
> > and as a result the messages are lost.
> 
Stephen Spackman wrote:

> But there are clear advantages to the buffered message approach as well (notably
> in being able to interleave messages from different passes in source order).

Yes, if all the messages from the later passes were still relevant despite
errors from earlier passes, this might be useful.  But I find that compilers
that do this usually drown the relevant first-pass messages in
oceans of consequent and incomprehensinle later-pass messages.

> What if the buffer flush were handled in exception unwind (or indeed in buffer
> finalisation)? Then unless the VM were destabilised - which shouldn't (ha ha)
> happen, the truth would still out....

Yes, in a undestabilizable Java machine, this might still get the news out,
unless the problem (such as limited disk space) were such as to
make it possible to emit only a limited number of messages.  IN this case,
I would prefer the the reported problems to be real problems, not
artifacts of the error recovery.
> 
> regards
> stephen p spackman <stephen@acm.org>
> 
-- hendrik@topoi,cam.org