In comp.lang.javascript message <eumugi$spv$1$8302bc10@news.demon.co.uk>
, Sun, 1 Apr 2007 01:31:20, Richard Cornford
<Richard@litotes.demon.co.ukposted:
Quote:
>
>The user should absolutely never see an error in their javascript
>console (or any other indication of an error). They should not see
>them mostly because software design, implementation, testing and
>QA should have identified and eliminated all sources of errors.
That's impractical. When a new browser version is released, it may have
a new bug, or a feature which, while compatible with ISO 16262, differs
from that of other browsers and from that which authors have not
doubted. Example : FF2 Date.UTC D<0 although that may be a true bug.
Authors cannot reasonably be expected to test all "live" pages with
every new browser version immediately on its release; they are often
asleep, on holiday, etc., at the time. Some, alas, are deceased.
When the javascript engine has reason to believe that the result cannot
be as the author intended, it should warn the user.
Probably each browser should have a choice of two error reporting levels
: (A) an Icon or Word of Warning (of non-trivial size) which when
selected pops up a "sorry, I cannot understand this page properly" with
suitable controls for, /inter alia/, giving fairly full debug info,
which would be given directly by (B).
Quote:
>But in practice users will not see errors because users will not
>enable active error reporting (and probably should not).
For the above reason, there should always be visible error indication.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "" (SonOfRFC1036)