[Web-SIG] New spec: throw_errors

[Luke Arno]

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.

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! ;)

> 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. ;)

Cheers,
- Luke