[Tutor] a program which list ALL the errors

[Mats Wichmann]

On 10/24/20 5:15 PM, Alan Gauld via Tutor wrote:
> On 24/10/2020 23:08, Cameron Simpson wrote:
>> On 18Oct2020 12:34, Alan Gauld <alan.gauld at yahoo.co.uk> wrote:
>>> But it must be said that its an unusual strategy.
>>> Most programs detect the first error and stop.
>>
>> And those programmes are user experience disasters. I hate them with a
>> passion.
> 
>> When that logic is buried deep in a subsidiary script, the user is 
>> massively annoyed. I submitted a small patch to probe for _all_ the 
>> software, complain about each missing comonepnt, and _then_ quit. Really 
>> easy and avoids much anger in the end user.
> 
> Interesting. I absolutely hate that behaviour. Some compilers
> do it and its a massive pain finding the first error and fixing
> it then trying to find another, and another,  and then discovering
> that fixing the first actually changed the second! It's much,
> much easier IMHO to fix one thing at a time.

It really depends on the context.

I've often run into this with the GNU autoconf stuff... try to configure
a program, and it fails. Install missing package, retry, fails. Repeat
several times.  Why?  In the case of an autoconf setup, the problems are
likely to be missing distribution packages, and it's nice to get those
all at once, rather than iterating, because you could just gang all the
needed installs into one command.  But I freely admit there are also
times where it's bad to spew all the errors, like with compilers - often
one problem will cascade through and potentially give you dozens to
hundreds of fails, and there's no value to spewing those, it's better to
just emit one, fix it, retry - and probably the fail list got massively
smaller.