Re: [Followup] Re: "Near Miss" error handling?

scott.daniels@acm.org wrote:
> On a related note, I have seen systems regularly rebuilt with hundreds
> of errors output, but the source was never corrected because it wasn't
> necessary -- carriage returns while compiling allowed systems to be
> successfully built and released. Such systems were still being
> debugged and extended without ever fixing the reported errors. I
> would suggest that you at _most_ offer to produce an equivalent
> corrected source on output, so that the user can only proceed with a
> cleanly compiling file. Interactively offering to correct a typo is
> reasonable to help out a user at a keyboard, but leads to weaker
> systems when extended to compiles from source files.


This seems reminiscent of the current situation of Javascript and HTML
on the web. The two main web browsers are deliberately lax about their
error checking, and contain code to deal with mistaken, but commonly
occurring script code.


This has led to the current situation where it's actually not possible
to build an independent web browser without selectively breaking its
parsing and execution logic in the same way as the other browsers.


This is because most people use the browser as their verification tool
also - "if it works, it must be correct".


A substantial proportion of the web contains invalid Javascript code
which will never be fixed, because it's not necessary. Nobody knows
what the "standard" is anymore; broken code is copied from place to
place by people who don't know any better, mutating a little each
time, and always keeping just inside the boundaries of the error
checks that the most common browsers perform.


As far as I'm aware, Internet Explorer silently fails on most parse
and run-time Javascript errors.


It becomes apparent that automatically correcting invalid programs can
lead to some particularly insidious problems...


    cheers,
        rog.

Return to the comp.compilers page.
Search the comp.compilers archives again.