this is just an idea, but you could catch KeyError s and log the stacktrace
before re-raising, that might help. something like
try:
return whatevs()
except Exception:
log.warning("error happened during traversal", exc_info=True)
On Wednesday, March 6, 2013 11:32:44 AM UTC-5, Peter Waller wrote:
>
> Thanks Steve for your great reply!
>
> In my use case, the "users" will (likely) not be using it as a platform as
> a service, but executing the pyramid application locally. My users will be
> comfortable with writing python and seeing stack traces.
>
> You're right that I will have to write documentation and teach them
> caveats. A lot of this stuff does "just work" though. Many people will
> learn from example code, which won't teach them that you have to be certain
> you can't ever raise a KeyError in the wrong place. In addition, I'm not
> sure _as an experienced python developer_ how to write code which
> guarantees it doesn't raise a KeyError.
>
> You've reminded me that I'm stuck at a microscopic level looking at one
> problem when there exist other things to worry about - especially once you
> throw other users writing code into the mix.
>
> However, I complain about this one behaviour for a specific reason: it's
> hell to debug. It's silent error passing. It's "that's funny, why is my
> data subtly wrong?" and a violation of the assumption that "if it's an
> exception, I'll get a stack trace (or error e-mail, or whatever), like I
> always do whenever there is an exception". I've spent a lot of time going
> "that's funny, why does it give me resource not found, this should
> definitely exist.."
>
> Brief thoughts inline.
>
> On 6 March 2013 16:05, Steve Schmechel <[email protected] <javascript:>>wrote:
>
>> In essence, you stated that you want to have "inexperienced users"
>> writing "untested code" that simply works. That is a very ambitious goal
>> and you probably have a great deal of work to do beyond getting traversal
>> to function, in order to have any hope of having system that can be stable
>> and maintainable by inexperienced users.
>>
>
> Indeed. It's ambitious, it might not work, it might be stupid. It works
> really well so far except for this one thing which has been a recurring
> issue for me.
>
> Are any exception messages going to be clear enough for them to know how
>> to take corrective action to fix an unforeseen problem in their own code,
>> without understanding the Pyramid internals? You probably need a whole
>> layer of code checking/introspection with custom feedback to guide the
>> users - *before* they deploy their code into the live system.
>>
>
> In this case I'm worried about the user using a dictionary (something
> they're likely to do) and just fat fingering something such that they cause
> a KeyError somewhere in the traversal. A stack trace telling them exactly
> what dictionary had a KeyError, and what the missing key is would be
> extremely helpful. It would at least not mean hours of trying to figure out
> why traversal appears not to be working at all.
>
>
>> If someone wants to select the color of their car at a dealership, they
>> don't hand them the manual for the painting robot at the assembly plant,
>> even if it is "the best painting robot manual ever written".
>>
>
> :D, I like this analogy. I will use it as I hand them the pyramid manual.
>
> If you don't handle all the possible problems in your code, it seems you
>> are simply delaying the point where your users must become Pyramid
>> developers, to when they experience their first bug and have to crack open
>> the Pyramid documentation to figure out how to fix it.
>>
>
> Yup. Except that this caveat isn't really explained anywhere that I've
> seen, so becoming a Pyramid developer won't help, to first order. That's
> one of my biggest problems with this, that I see there might well be bugs
> lurking in existing applications, since I managed to write a lot of code
> before I encountered this problem. And then I managed to use my application
> and encounter weird issues for quite some time before I understood the root
> cause.
>
>
>> For most people building stuff on top of Pyramid, the fact that it is
>> simple, stable, and thoroughly tested is of greater importance then the
>> ease of integrating it into every conceivable use case. I really do not
>> need or want a bunch of framework-specific exceptions thrust upon me to add
>> to my learning curve. And if I someday want some, I will override what I
>> need to in order to add them.
>>
>
>
> I think that is probably what you are going too need to do.
>>
>
> I very much appreciate this and I'm quite happy to be told "no changes to
> pyramid, go away". I haven't seen any other discussion on this matter
> though, so I thought it was worth having an exhaustive discussion.
>
> I read what I've written and I hate the whiny tone, so I should probably
> stop talking now. If you read this far, thanks. Again, I love the way the
> project is and by no means am I saying "my way is right" (I don't even have
> a way..), I just would love to see a clean solution to this. Maybe copying
> the existing traverser and excising the catch is it.
>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
