Re: Lilypond error behaviour

[Urs Liska]

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: error: syntax error, unexpected end of input

c

'

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.

That LilyPond should
refrain from completing the current PDF it has open and make sure that
it is invalid or deleted?  

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.

What if the input file generated more than
one PDF?  Should it delete or invalidate the PDF files it has written
previously?  What if it had already written a PDF but fails during
generation of a MIDI or vice versa?

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

When is a stop forced?  Is LilyPond allowed to produce an error message
before crashing?

Maybe "stop forced" isn't the perfect term either. Replace that with when the error prevents LilyPond from producing output.
If LilyPond crashes then obviously any error handling has failed, so that shouldn't be taken into account here.