[Web-SIG] New spec: throw_errors

[Luke Arno]

On 11/14/06, Ian Bicking <ianb at colorstudy.com> wrote:
> Luke Arno wrote:
> > On 11/14/06, Ian Bicking <ianb at colorstudy.com> wrote:
> >> Luke Arno wrote:
> >> > -1 to the proposed spec
> >> >
> >> > On 11/13/06, Ian Bicking <ianb at colorstudy.com> wrote:
> >> > ...
> >> >> Other Possibilities
> >> >> -------------------
> >> >>
> >> >> * You can just get the unwrapped application object and test it.
> >> >
> >> > +1, emphatically
> >> >
> >> > Let's encourage best practices, before we
> >> > standardize specific workarounds.
> >> >
> >> > The unwrapped version of the object should also be
> >> > made available for composition purposes, if it is
> >> > intended for such.
> >>
> >> OK, then, you're going to have to justify that, because I don't think
> >> it's best practice ;)
> >
> > I don't know what "justify" means in this context but
> > I will try to explain.
> >
> >> In particular, in many frameworks the presence of an exception catcher
> >> is automatic and largely opaque to the user.  Of course it doesn't
> >> *have* to be opaque, but because this is the only case where it really
> >> matters I don't see why it shouldn't be opaque -- it's not worth
> >> explaining.
> >
> > I don't see why it should be opaque. It is just as easy
> > to explain as your environ flag. Plus it is simpler and
> > more explicit.
>
> The only people who have to understand the environ flag are testing
> system writers, and exception catching writers.  For everyone else it
> Just Works.  In your model you have to understand the layout of the
> middleware and where you can get the unwrapped application object.

Who is this "middle class programmer" who conducts
testing yet is so clueless of what he tests? Me thinks
he just follows the instructions on his end to end
framework and will not be affected either way.

> > This is a common pattern: application user interface
> > and application programming interface. Here is the
> > external, friendly, error-hiding app that you run by
> > itself in production. Here is the raw app that you test
> > and plug into the back of some larger app. And there
> > is no additional config data to manage. Hooray! ;)
>
> For the most common default case there is no additional config required;
> the default is for the key to be respected and then everything works
> appropriately.  While you *can* ignore the key, I've never had a reason
> to do so.  I can imagine such a case exists, which is why ignoring the
> key should be an option (and of course you can't *make* anyone pay
> attention to anything).

But what about composition? What about a reusable
WebDAV component, for instance? You could run it
as a stand-alone app and you would have the flag
set to False. Then you plug it in as part of an app
that just wants to include a little DAV. If the flag is
set to False, the "master" application can't deal with
errors intelligently or pass them along to it's error
middleware, but if it is True, all the errors fly loose.

I for one would like to see composability increase
and avoid this sort of coupling.

> >> It's not opaque to me, of course, and yet I never feel a need to unpack
> >> the object this way, because the one reason I might have is satisfied
> >> transparently, automatically, and reliably by this environment
> >> convention.
> >>
> >> Exception handling is something that is generally handled by some
> >> particular pieces of software -- the exception catcher and test
> >> frameworks.  If they can agree on this, I don't see a reason anyone else
> >> needs to think about it.
> >
> > If the exception catcher isn't being put between the
> > app and the test framework, there is no problem to
> > solve or think about.
> >
> > I prefer non-problems to clever solutions. ;)
>
> You've pushed the problem out of the framework and into the user's
> understanding of and ability to decompose the framework.

I _want_ composability and decomposability.
That is the exact approach I would like to see.
Let's encourage this kind of understanding.

> The problem
> still exists; if your exception catcher is in place when you run the
> tests you'll get really unhelpful output.

So, don't do that. It is easy to explain why and
how not to. If a programmer does not understand
exception handling yet, he should be taught.
Let's educate the programmer if needed rather
than kludging around his ignorance.

> And, as a final argument: this is a *really easy* spec to support.

can != should :)

Cheers,
- Luke