Re: Lilypond error behaviour

[David Kastrup]

Urs Liska <address@hidden> writes:

> Am 17.04.2016 um 12:33 schrieb David Kastrup:
>> Urs Liska <address@hidden> writes:
>>
>>> Am 17. April 2016 10:51:34 MESZ, schrieb David Kastrup <address@hidden>:
>>>> Urs Liska <address@hidden> writes:
>>>>
>>>>> Am 17. April 2016 08:20:52 MESZ, schrieb David Kastrup <address@hidden>:
>>>>>
>>>>>> A warning is appropriate for something which is not an error: namely
>>>>>> LilyPond has a well-specified task but the results will not likely
>>>>>> make sense.  LilyPond does not return an error code for a warning.
>>>>> Well, then let LilyPond report an error when it encounters one. But
>>>>> only then a "fatal" one when it actually forces LilyPond to stop.
>>>> For any _correct_ input, LilyPond is eventually forced to stop.
>>> This is the point where I have to say you are talking bullshit,
>>> deliberately (?) and arbitrarily flipping around everyone's words and
>>> intentions. It doesn't make sense to continue with that thread.
>> So what does "force to stop" mean in your opinion?  
>
> \version "2.19.40"
>
> {
>   c'
>
> produces:
>
> /tmp/frescobaldi-hp7_ll/tmpoyBSnr/document.ly:4:4 <0>: error: syntax
> error, unexpected end of input
>
> c
>
> '

How is this substantially different from

{ c' }
{

here?

GNU LilyPond 2.19.32
Processing `dog.ly'
Parsing...
dog.ly:2:2: error: syntax error, unexpected end of input
{
 
dog.ly:1: warning: no \version statement found, please add

\version "2.19.32"

for future compatibility
Interpreting music...
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `/tmp/lilypond-EZC6cx'...
Converting to `dog.pdf'...
Deleting `/tmp/lilypond-EZC6cx'...
fatal error: failed files: "dog.ly"

> fatal error: failed files: "/tmp/frescobaldi-hp7_ll/tmpoyBSnr/document.ly"
>
> and it is obivous that LilyPond wasn't able to produce a file. This is
> the class of errors where I think the label "fatal" is appropriate.

So in my example it did produce a file.  The error was exactly the same
kind of error.  Now it is no longer fatal?  Because there was something
before the error that _did_ produce output?

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

So why is the above error no longer fatal, and why can one now consider
LilyPond as having succeeded in compiling the file?

> I would say if LilyPond is able to produce files for all targets that
> are requested by the input file then the compilation didn't "fail".

Ok, so now here magically there was no failure.  One problem with your
definition is that with syntax errors present you don't even _know_
whether or not the input file requested some target.

> If it produced "error" messages along the way then "compilation
> completed with errors" or something like that but compilation didn't
> fail.
>
>>
>> I don't get the obsession with "it is not an error if LilyPond does
>> not immediately crash and leaves bad output or none at all".
>
> Obviously you don't get it because you seem obsessed by the word
> "error" while gating out the word "fatal".

Is the error in the file I showed fatal or not?

-- 
David Kastrup