[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.
- Re: Lilypond error behaviour, (continued)
- Re: Lilypond error behaviour, Thomas Morley, 2016/04/17
- Re: Lilypond error behaviour, Thomas Morley, 2016/04/18
- Re: Lilypond error behaviour, Noeck, 2016/04/18
- Re: Lilypond error behaviour, Sharon Rosner, 2016/04/17
- Re: Lilypond error behaviour, David Kastrup, 2016/04/17
- Re: Lilypond error behaviour, Sharon Rosner, 2016/04/18
- Re: Lilypond error behaviour, mskala, 2016/04/18
- Re: Lilypond error behaviour,
David Wright <=
- Re: Lilypond error behaviour, mskala, 2016/04/18
- Re: Lilypond error behaviour, David Kastrup, 2016/04/18
- Re: Lilypond error behaviour, mskala, 2016/04/18
- Re: Lilypond error behaviour, Sharon Rosner, 2016/04/18
- Re: Lilypond error behaviour, Anthonys Lists, 2016/04/18
- Re: Lilypond error behaviour, Sharon Rosner, 2016/04/18
- Re: Lilypond error behaviour, Sharon Rosner, 2016/04/18
- Re: Lilypond error behaviour, Noeck, 2016/04/19
- Re: Lilypond error behaviour, mskala, 2016/04/19
- Re: Lilypond error behaviour, Thomas Morley, 2016/04/19