Re: Lilypond error behaviour

[mskala]

On Mon, 18 Apr 2016, Sharon Rosner wrote:
> I’m not saying that lilypond’s behaviour is necessarily wrong. I’m just
> trying to point out, like others have, that the term “fatal error” would
> normally mean that the program was unable to continue processing.

I run Lilypond in Make, like a compiler, and I wish it would handle errors
the way compilers do.  That means:  a fatal error is one that prevents it
from *finishing* processing.  The program might not necessarily stop
instantly upon detecting a fatal error - most compilers will attempt to
press ahead in order to be able to provide more information about this or
other errors - but once a fatal error has been detected, it's known that
there will not be a successful completion.  Much like the meaning of the
word "fatal" outside computing:  a fatal wound is one that will kill you
eventually.  You might not be dead yet, when you have suffered a fatal wound.

Working like a compiler also means that if a fatal error occurs, the file
that failed is not written.  If it had been partially written before
then, it is *deleted*.  Not patched up to look sort of okay.  Deleting it
is important so that Make, and other build tools, can correctly
distinguish the bad file from a correct one.  Returning an "error" exit
code is important too, but does not serve the same purpose, because it
only notifies the parent process, not future tools looking at the files
left behind.

Fortunately, Make will unless configured otherwise delete the bad file
itself anyway, instead of depending on a broken compiler to do so.  But
the compiler that doesn't clean up its own mess, *is* broken.

-- 
Matthew Skala
address@hidden                 People before principles.
http://ansuz.sooke.bc.ca/