[whatwg] canvas 2d's ellipse

[Rik Cabanier]

On Tue, Sep 17, 2013 at 11:31 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 17 Sep 2013, Tab Atkins Jr. wrote:
> > >
> > > I'm not a fan of "sweep it under the carpet" bug handling, personally.
> > > It drives me crazy that JavaScript has no type checking, no argument
> > > checking, etc. So many bugs that should be caught at compile time, or
> > > at least at runtime when the code is reached, are instead caught only
> > > after careful testing.
> >
> > "Runtime when the code is reached" often actually means "Whoops! Now the
> > entire app's broken because I forgot to handle a silly edge-case.".
> > When there's an easy and obvious recovery strategy, it's often much
> > friendlier to authors to take it rather than force them to handle
> > errors.
>
> Usually in these cases the entire app is probably still broken -- maybe
> with data corruption, even, or with confusingly bad behaviour. The only
> difference is that you have no idea where to begin looking.
>

Ok, so what if *some* applications would be horribly broken. *Others* will
still stumble along  or work perfectly fine.
I'd rather have that, than a completely broken page.


>
> It wouldn't be so bad if we had a way to have errors that allowed the code
> to continue anyway, the way we do e.g. in HTML parsing, where you can
> easily run a validator to find out what you've done wrong, while still
> having the errors swept under the carpet on the user's end.


The browser could log something in the console output so the developer can
debug it.
Maybe the spec could say that the operation is in error but that processing
will continue as if the bad call didn't happen.