Sharon Rosner <[email protected]> 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 _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
