[Web-SIG] New spec: throw_errors

[Ian Bicking]

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.

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

>> 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.  The problem 
still exists; if your exception catcher is in place when you run the 
tests you'll get really unhelpful output.

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

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org