> 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. _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user