[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lilypond error behaviour
From: |
Thomas Morley |
Subject: |
Re: Lilypond error behaviour |
Date: |
Sun, 17 Apr 2016 16:20:27 +0200 |
2016-04-17 13:59 GMT+02:00 <address@hidden>:
> On Sun, 17 Apr 2016, Urs Liska wrote:
>> No, of course not. If LilyPond is able to "recover" (as Andrew put it) it
>> should of course do so. But it should not report a "fatal error" and a
>> "failed file" then.
>
> I think the whole thing comes down to something very simple which
> ought to go without saying, but evidently needs to be said after all:
>
> Lilypond should not lie.
Does she?
Look at the sippet below where I accumulated several errors:
%%%% snippet start
\version "1.7.2"
(display "whatever")
\foo
{ c''1 }
{
#(format #t "~a\n"
(assoc 'avoid-slur (assoc-get 'Accidental all-grob-descriptions)))
%{
%%%% snippet end !!
In terminal I see:
(1) for the version:
error: file too old: 1.7.2 (oldest supported: 2.7.38)
error: consider updating the input with the convert-ly script
(2) for `(display "whatever")' without leading #-sign
atest-218.ly:3:1: error: syntax error, unexpected EVENT_IDENTIFIER
(display "whatever")
(3) for the call of undefined `foo'
atest-218.ly:5:1: error: unknown escaped string: `\foo'
\foo
(4) for the opening `{' followed by #(format ...)
(avoid-slur . inside)
atest-218.ly:10:1: warning: Ignoring non-music expression
#(format #t "~a\n"
(5) for the not finished block-comment
atest-218.ly:13:3: error: EOF found inside a comment
%{
atest-218.ly:13:3: error: syntax error, unexpected end of input
%{
All of them are "non_fatal_error" errors, correctly reported! LilyPond
continues outputting a pdf.
In the very end she throws a more or less summarizing _fatal_ error _and_ exits.
`Success: compilation successfully completed' is missing!
(Or look in flower/warn.cc and lily/lexer.ll)
It's LilyPonds most important goal to produce some printed output. And
she succeeds even by such a messy input.
The reason throwing the fatal error but not exiting before is
explained in the CG-link Simon already provided.
Is it a lie throwing such an summarizing fatal error in order to
protect our user-, bug- and devel-mailing-lists from users not paying
attention what they are told by non_fatal_errors (and warnings)?
I know several examples where people continued happily ignoring all
until the file contained several thousand lines and finally something
in that mess caused an _immidiate_ fatal error. Then they shine up on
mailing-lists and forums complaining and asking for help.
Otoh, I think I understand why Andrew needs to triage the differently
severe errors.
But the only thing I can think of is to treat _any_ error/warning as
fatal setting
#(ly:set-option 'warning-as-error)
or using the command-line version
-dwarning-as-error
Cheers,
Harm
- Re: Lilypond error behaviour, (continued)
- Re: Lilypond error behaviour, Andrew Bernard, 2016/04/17
- Re: Lilypond error behaviour, David Kastrup, 2016/04/17
- Re: Lilypond error behaviour, Urs Liska, 2016/04/17
- Re: Lilypond error behaviour, David Kastrup, 2016/04/17
- Re: Lilypond error behaviour, Urs Liska, 2016/04/17
- Re: Lilypond error behaviour, David Kastrup, 2016/04/17
- Re: Lilypond error behaviour, Urs Liska, 2016/04/17
- Re: Lilypond error behaviour, mskala, 2016/04/17
- Re: Lilypond error behaviour,
Thomas Morley <=
- Re: Lilypond error behaviour, David Kastrup, 2016/04/17
- Re: Lilypond error behaviour, Kieren MacMillan, 2016/04/17
- Re: Lilypond error behaviour, David Kastrup, 2016/04/17
- Re: Lilypond error behaviour, Kieren MacMillan, 2016/04/17
- Re: Lilypond error behaviour, Noeck, 2016/04/17
- Re: Lilypond error behaviour, David Kastrup, 2016/04/17
- Re: Lilypond error behaviour, Tim McNamara, 2016/04/17
- Re: Lilypond error behaviour, Noeck, 2016/04/18
- Re: Lilypond error behaviour, Thomas Morley, 2016/04/17
- Re: Lilypond error behaviour, Thomas Morley, 2016/04/18