Dave Mitchell <davem@iabyn.com> wrote: :I've always been very dubious about trying to continue parsing generally :after an error has been encountered. We've spent years trying to fix all :the bugs and SEGVs that this causes. : :I've rarely found the extra error messages it produces useful: in both C :and perl I tend to just look at and fix the first error reported, then :recompile. Long gone are the days where you would have to wait minutes to :recompile a source file (or wait for a compile report to be posted back to :you from the Data Centre). : :I'd be interested to hear opposing opinions or counter-examples though. I quite regularly find more than one error message useful when I've just added or changed a largish swathe of code (maybe 50-200 lines). That's usually a bunch of simple mechanical errors such as typos and missing semicolons. In most cases even so it would not be a problem to get those one at a time, but at a previous $workplace most of the code could not be run or even compile-tested on the same system where the revision control system could run, nor easily even on the target system without complex setup. So it was either an scp + app-restart cycle (around 60s turnaround) for each edit, or for slightly faster turnaround edit on the target system and then risk failing to correctly duplicate those changes onto the source system for commit. I recognise that that was a deeply suboptimal setup; I don't know how widespread similar setups might be though, or to what extent we should try to cater for them. HugoThread Previous | Thread Next