[Bug 16608] Algorithms should rethrow the exception

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16608

--- Comment #6 from Glenn Maynard <glenn@zewt.org> 2012-04-03 14:35:53 UTC ---
> Also, it seems rather confusing to silently eat exceptions in this spec

I'm confused--currently the spec is silently handling exceptions, and I'm
saying it should be explicit, not silent.

HTML does explicitly catch and re-throw exceptions, eg.
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html:

"Let cloned data be a structured clone of the specified data. If this throws an
exception, then rethrow that exception and abort these steps."

I don't know if it does this consistently, but it should.

> This way of throwing exceptions also matches how exceptions work in programming.

I'm not a fan of Java's checked exceptions for most development (and I hate
making the analogy at all), but when you need to be sure that everyone is
properly handling exceptions in every possible case, as specs require, they're
what you want.

Finally, you should be able to look at any algorithm in isolation and be able
to immediately understand its logical flow and exit points.

> there is no need to redefine it because otherwise you might get conflicts in behavior (specially if the underlying spec changes beneath you). 

This is exactly why exceptions need to be handled explicitly.  If you're
calling an algorithm with the expectation that it doesn't fail, then that spec
*can't* be changed to throw an exception, unless you change your spec to deal
with that.

For example, see
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-canvas-getcontext.
 This calls the "Return a new object for contextId" algorithms in other specs. 
This algorithm logically fails if that algorithm throws an exception, because
it would incorrect leave the "primary context" set, and step 5 wouldn't make
sense because it assumes that step 6 always completes.

If you want to define a "return a new object for" algorithm that defines an
exception, you'd first need to have this algorithm updated, so it's written in
a way that expects it.  Currently, you can't write an algorithm that does that;
it's logically invalid and would be a spec bug.  If Canvas said "all exceptions
are simply propagated upwards", all that does is implicitly allow other specs
to throw exceptions in unexpected and broken ways.

I can't imagine how much would break if "decode a byte string as UTF-8, with
error handling" or "Converting a string to ASCII uppercase" suddenly started
throwing exceptions.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 3 April 2012 14:36:06 UTC