|
|
|
|
|
|
| Author |
Message |
Steve Holden
*nix forums Guru
Joined: 22 Feb 2005
Posts: 1255
|
 Posted: Fri Jul 21, 2006 10:48 am Post subject:
Re: Semantics of propagated exceptions
|
|
|
Thomas Lotze wrote:
| Quote: | Hi,
I wonder how to solve the following problem the most pythonic way:
Suppose you have a function f which, as part of its protocol, raises some
standard exception E under certain, well-defined circumstances. Suppose
further that f calls other functions which may also raise E. How to best
distinguish whether an exception E raised by f has the meaning defined by
the protocol or just comes from details of the implementation?
As an example, let's inherit from dict and replace __getitem__. It is
supposed to raise a KeyError if an item is not found in the mapping. But
what if it does some magic to use default values:
def __getitem__(self, key):
if key in self:
return self[key]
defaults = foobar["default"]
return defaults[key]
If "default" is not in foobar, a KeyError is raised by that lookup and
propagates to the calling code. However, the problem is not "key can't be
found" but "I'm too stupid to find out whether key can be found". In a web
context where key identifies the resource requested, this might make the
difference between a 404 "Not found" and a 500 "Internal server error"
response.
The obvious response is to make the implementation less stupid by |
replacing the last statement with
try:
return defaults[key]
except KeyError:
raise KeyError("No default for key value %s" % key)
| Quote: | Several solutions come to mind, neither of which I'm satisfied with:
- f might catch E exceptions from the implementation and raise some other
error in their stead, maybe with an appropriate message or treating the
traceback in some helpful way. This destroys the original exception.
My "solution", of course, takes this approach. The error can readily be |
recognised as different from the standard KeyError message. The original
exception is worthless in this context as your new type is clearly
supposed to provide a default for any absent key value. The handling
code should thus treat the key's absence as some sort of implementation
error.
| Quote: | - f might catch and re-raise E exceptions, setting some flag on them that
identifies them as protocol exceptions or not. This requires calling code
to know about the flag.
This doesn't seem particularly helpful in your case. Since the purpose |
of the flag is to distinguish the actual exception thrown by your type
from the exception thrown during method execution it would seem more
direct to use a different exception altogether.
| Quote: | - Calling code might guess whether the exception comes from some inner
working of f from how deep in the calling stack the exception originated.
Obviously, this will not be easy or not even work at all if f calls
related functions which might also raise E with the protocol semantics.
This requires calling code to do some magic but keeps f from having to
catch and raise exceptions all over the place.
The problem with this approach is that the more complex your |
implementations become, the more complex the client (calling) code has
to be. It will probably also require serious changes to the calling code
as implementation details change, which doesn't give very good isolation.
| Quote: | Some gut feeling tells me the first option is preferrable, but I'ld like
to read your opinions and maybe other alternatives.
|
Just my two cents worth.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden |
|
| Back to top |
|
 |
Marc 'BlackJack' Rintsch
*nix forums Guru Wannabe
Joined: 03 Mar 2005
Posts: 146
|
| Posted: Fri Jul 21, 2006 10:47 am Post subject:
Re: Semantics of propagated exceptions
|
|
|
In <pan.2006.07.21.09.57.12.847175@ID-174572.user.uni-berlin.de>, Thomas
Lotze wrote:
| Quote: | I wonder how to solve the following problem the most pythonic way:
Suppose you have a function f which, as part of its protocol, raises some
standard exception E under certain, well-defined circumstances. Suppose
further that f calls other functions which may also raise E. How to best
distinguish whether an exception E raised by f has the meaning defined by
the protocol or just comes from details of the implementation?
[…]
Several solutions come to mind, neither of which I'm satisfied with:
- f might catch E exceptions from the implementation and raise some other
error in their stead, maybe with an appropriate message or treating the
traceback in some helpful way. This destroys the original exception.
|
This is the way to go I think. After all it's not an ordinary `E` but one
that has a special, well defined meaning if raised by `f` itself according
to your protocol.
Put the original exception as an attribute to the new one and/or subclass
the new exception type from `E`. This way calling code can choose to to
handle both types as `E` if the distinction is not important.
Ciao,
Marc 'BlackJack' Rintsch |
|
| Back to top |
|
|
Lawrence D'Oliveiro
*nix forums Guru
Joined: 25 Mar 2005
Posts: 723
|
| Posted: Fri Jul 21, 2006 10:39 am Post subject:
Re: Semantics of propagated exceptions
|
|
|
In message <pan.2006.07.21.09.57.12.847175@ID-174572.user.uni-berlin.de>,
Thomas Lotze wrote:
| Quote: | Suppose you have a function f which, as part of its protocol, raises some
standard exception E under certain, well-defined circumstances. Suppose
further that f calls other functions which may also raise E. How to best
distinguish whether an exception E raised by f has the meaning defined by
the protocol or just comes from details of the implementation?
|
You can't. All the information necessary to identify the exception must be
in the exception object itself. If you want to distinguish between
exceptions raised by F and those raised by other functions called by F,
then they must be different exceptions. |
|
| Back to top |
|
|
Thomas Lotze
*nix forums beginner
Joined: 28 Feb 2005
Posts: 38
|
| Posted: Fri Jul 21, 2006 9:57 am Post subject:
Semantics of propagated exceptions
|
|
|
Hi,
I wonder how to solve the following problem the most pythonic way:
Suppose you have a function f which, as part of its protocol, raises some
standard exception E under certain, well-defined circumstances. Suppose
further that f calls other functions which may also raise E. How to best
distinguish whether an exception E raised by f has the meaning defined by
the protocol or just comes from details of the implementation?
As an example, let's inherit from dict and replace __getitem__. It is
supposed to raise a KeyError if an item is not found in the mapping. But
what if it does some magic to use default values:
def __getitem__(self, key):
if key in self:
return self[key]
defaults = foobar["default"]
return defaults[key]
If "default" is not in foobar, a KeyError is raised by that lookup and
propagates to the calling code. However, the problem is not "key can't be
found" but "I'm too stupid to find out whether key can be found". In a web
context where key identifies the resource requested, this might make the
difference between a 404 "Not found" and a 500 "Internal server error"
response.
Several solutions come to mind, neither of which I'm satisfied with:
- f might catch E exceptions from the implementation and raise some other
error in their stead, maybe with an appropriate message or treating the
traceback in some helpful way. This destroys the original exception.
- f might catch and re-raise E exceptions, setting some flag on them that
identifies them as protocol exceptions or not. This requires calling code
to know about the flag.
- Calling code might guess whether the exception comes from some inner
working of f from how deep in the calling stack the exception originated.
Obviously, this will not be easy or not even work at all if f calls
related functions which might also raise E with the protocol semantics.
This requires calling code to do some magic but keeps f from having to
catch and raise exceptions all over the place.
Some gut feeling tells me the first option is preferrable, but I'ld like
to read your opinions and maybe other alternatives.
--
Thomas |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Thu Nov 20, 2008 8:19 am | All times are GMT
|
|
Hosting | Bikini Model | Mortgages | Problem Mortgage | Credit Cards
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Programming
»
python
