Re: Lilypond error behaviour

[Sharon Rosner]

> The non-fatal errors are re-raised as a fatal error after the pdf is
> produced just to alert the user in the end that there were errors. And I
> think that is what confuses most people here. The error was non-fatal
> but still after everything is done, an additional fatal error is raised
> to draw attention to previous non-fatal errors.

I understand, but to me this does not make sense. If the error was not
fatal, and lilypond has indeed continued processing the file and producing
the output, then what's the point of raising a fatal error? As I wrote
before, according to the docs a fatal error is defined as follows:
"Something is definitely wrong, and LilyPond cannot continue." Do you see
the contradiction here?

And I'd add that if Lilypond has indeed succeeded in rendering the bad input
file, and has clearly displayed syntax errors and their location on stderr,
why should it exit with an error code? Doesn't the user already have enough
diagnostics?

There's also the issue I demonstrated with the warning-as-error option,
which causes further confusion, since it makes the normal non-fatal syntax
errors into *real* fatal errors, which cause lilypond to exit immediately
upon a syntax error, even though its stated function is to convert warnings
into errors. However, looking at the docs I found this (
http://lilypond.org/doc/v2.19/Documentation/contributor/warnings-errors-progress-and-debug-output.html
<http://lilypond.org/doc/v2.19/Documentation/contributor/warnings-errors-progress-and-debug-output.html>
 
):

"The error functions come in three different flavors: fatal error messages,
programming error messages and normal error messages. Errors written by the
error () function will cause LilyPond to exit immediately, errors by
Input::error () will continue the compilation, but return a non-zero return
value of the LilyPond call (i.e. indicate an unsuccessful program
execution). All other errors will be printed on the console, but not exit
LilyPond or indicate an unsuccessful return code. Their only differences to
a warnings are the displayed text and that they will be shown with loglevel
ERROR.

"If the Scheme option warning-as-error is set, any warning will be treated
as if Input::error was called."

So it's clear why warning-as-error has the effect it does. I'm sorry but the
current behaviour to me seems incoherent - it mixes warnings with errors,
and success with failure.

Sharon



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Lilypond-error-behaviour-tp189622p189748.html
Sent from the User mailing list archive at Nabble.com.