Re: Lilypond error behaviour

[David Kastrup]

Sharon Rosner <address@hidden> writes:

>> More exactly, LilyPond's task is to read a LilyPond input file and
>> process its contained expression according to the setting of hook
>> variables (those may do something other than typesetting, for example
>> converting to a MusicXML expression and writing it out again).  Some
>> processing may result in files being generated (including PDF files).
>> But the generation of PDF files is a side effect.  It does not have a
>> relation to the occurence of errors.
>
> OK, I think I finally get it. But then why are the errors classified
> as “fatal”?

Because LilyPond was unable to make sense of the input and just
attempted some kind of error recovery in order to carry on.  When you
have a file needing an hour of processing, you don't really want to have
LilyPond abort for trivial errors like misspelling gis as giss even
though LilyPond knows that it cannot offer a PDF file in complete
correspondence with the input.

> Is it only so that the exit code would be non-zero?

That is one consequence.

> Is this the difference between fatal and non-fatal errors? If so,
> maybe a better term could be used?

A non-fatal error is one where LilyPond continues processing.  At the
end of LilyPond's processing, a fatal error is raised summarily when any
non-fatal error occured.

One could change this to a normal message to shut people up, but the
message would still need to make very clear that LilyPond was not able
to successfully process the input, and of course there must be an exit
status signifying an error.

In short, nothing would change apart possibly from the output to the
terminal, and the output to the terminal should still at the very bottom
indicate an error that made it unable for LilyPond to consider the run
successful.

-- 
David Kastrup