lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lilypond error behaviour


From: David Wright
Subject: Re: Lilypond error behaviour
Date: Mon, 18 Apr 2016 11:56:16 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon 18 Apr 2016 at 03:23:31 (-0500), address@hidden wrote:
> 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.

So satisfyling your "make" is more important that my chance to eyeball
the (possibly a) mess that I have created?

> 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.

Let's not lose sight of the fact that LP is a music notation program,
not a compiler. Whether an object file is in a fit state to be linked
may be a decision that a machine can make, but whether a PDF is
suitable for further use (to debug the source code, give to a player,
or admire on the coffee table) is not.

Cheers,
David.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]