Re: Lilypond error behaviour

[Stephan Neuhaus]

On 2016-04-17 13:51, Urs Liska wrote:
> Am 17.04.2016 um 04:29 schrieb David Wright:
> > I think a better analogy than compilers writing programs would be
> > browsers rendering web pages. Can you imagine a WWW where malformed
> > pages produced a few error messages on the screen and nothing else?
> > No, we expect the browser to make its best attempt at a partial
> > rendition. So please leave LP alone and write a better server.
> > Yes, it might be nice if LP had an indication of severity level,
> > but my preference would be for improvements in LP's primary goals.
>
> I think the browser is indeed a good analogy.
>
> If we have malformed HTML or even worse issues like e.g. a failed CSS
> include, then yes, we expect the browser to render as much and as nice
> as possible. But what LilyPond currently does is displaying a big modal
> over the page saying "I'm sorry but I couldn't render the page due to a
> fatal error. Please click here to close this message and view the page."

Coming at this discussion rather late, and also from a totally different 
angle, I'd like to make the (slightly off-topic) point that I don't 
think that it's a good idea to make it a design principle that Lilypond 
should try to render even clearly malformed input.

(Note that I'm not saying that it is a happy coincidence that Lilypond 
does, in fact, do this.  It's great for debugging, as I can attest.  All 
I'm saying is that it would be a bad idea for users to rely on this 
behaviour, and for Lilypond developers to embrace it as a design principle.)

We have seen in HTML how malformed input quickly becomes the norm and 
how browser vendors are unable to back out of supporting it. (Just try 
to validate almost any web page that claims to be HTML 4.01 and you'll 
see what I mean.) The result is that render engines are much slower and 
much buggier than they need to be, because they have tons of exceptions 
for stuff that isn't really HTML but where the blame would ultimately 
fall on the browser if it didn't render properly.

(I'm not saying that I advocate browsers refusing to render something 
that is almost, but not quite, entirely unlike HTML.  I'm just saying 
that once you go down that rabbit hole, you won't come back up in a hurry.)

Personally, I like the idea of Lilypond clearly saying to the user that 
there is something wrong with the input file. If that "modal dialog" 
went away, users would simply look at the output file and conclude that 
their input must have been OK. Having a clear and unambiguous message 
(even if there is debate about the use of the word "fatal") that _there 
is something wrong with the input file_ frees Lilypond developers to 
extend and otherwise develop Lilypond without the burden of having to 
support wrong but entrenched usage.

Fun,

Stephan