View Single Post
Old 06-02-2016, 10:43 AM   #4
theducks
Well trained by Cats
theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.theducks ought to be getting tired of karma fortunes by now.
 
theducks's Avatar
 
Posts: 31,141
Karma: 60406498
Join Date: Aug 2009
Location: The Central Coast of California
Device: Kobo Libra2,Kobo Aura2v1, K4NT(Fixed: New Bat.), Galaxy Tab A
Quote:
Originally Posted by chaot View Post
Reference (presumably): Because when a parsing error occurrs, all further error checking is aborted.

No concept without rule/s. Otherwise it's arbitrary.

If I understand correctly, no other types of errors, mistakes etc. may be displayed upon the occurrence of parsing errors. In the present case, however, only exist parsing errors, altogether 75.

Why are only 3 displayed? Why these 3?

By no means I want to annoy with pedantic questions. But a satisfactory answer I need for my understanding of the matter.
Because, that is the way it works
Many cleaning programs require multiple 'passes' to find and expose the 'next error' after a repair.

It keeps things simpler, just to stop when it hits a Parse error, rather than figure what it would take to MEANINGFULLY continue

I have been using computers from before the IBM PC. It has always been a standard debug technique to:
run, fix, run
until the compiler finishes without error (PS I have lots of BUG creation and fixing practice )
theducks is offline   Reply With Quote