On Wednesday, 6 March 2013 02:43:11 UTC, Whit Morriss wrote: > so my question is what are you doing (or expecting to happen) inside > __getitem__ where you get unexpected key errors? >
The problem is that I don't know, because I can't predict the future, nor can I predict what code *other* people might write. Yes, dictionary lookups are the main way I've encountered this issue so far. But it is quite easy to write erroneous code which causes a KeyError, in fact, people messing with dictionaries when they develop their own resources is a very likely occurrence. The problem is that in complicated code, functions you call might call functions which raise KeyError somewhere, so you can't tell just by looking at the __getitem__ implementation whether it is KeyError safe. That means you have to always wrap your entire __getitem__ implementation to catch KeyError and rethrow it as a different exception, or something. (And of course, if you really mean KeyError->NoResource, you have to handle that case too). It's a mess. On Wednesday, 6 March 2013 02:52:21 UTC, Michael Merickel wrote: > > If this isn't making sense, you'll need to provide some clearer info on > what you mean by "resource not found" and what exact behavior you're seeing > in your app. The __getitem__ is the place where most of my users might write their code. I don't get to choose whether they remember to write try/except around the entire function just in case there might be a latent bug anywhere inside any of the functions they call which allows a KeyError to propagate upwards. To exacerbate this problem, I've developed something I call a MultiTraverser. Basically, it allows you to have wildcards in the URL fragments. This ends up with the traversal of a cartesian-product of resources over URL fragments (i.e, a single URL can end up hitting a lot of resources). Having resources randomly not present in my case because they accidentally raised a KeyError is a pretty fatal problem for my use case. A resource might be just one component in some data analysis - a component randomly not being there (because it is buggy and raises a KeyError accidentally) could easily be missed by a user and lead to incorrect results. It seems that if I want to make this reasonably fool-proof I have to invent my own traverser. Any advice on that front? Thanks again, - Peter -- 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.
