4

So I'm interacting with a 3rd party library, which raises exceptions someti0mes, but it raises the same exception for basically everything (specifically suds.WebFault. It's possible however to determine the exact type of exception it is from the data on the exception raised. I'm looking to abstract this exception into exceptions that subclass this type, ie:

from suds import WebFault

class MoreSpecificError(WebFault):
    pass

I like the subclassing, because it won't break existing implementations that expect a WebFault. The problem I'm having is passing the data already on the WebFault into the MoreSpecificError. What I would like to do is take the existing exception object and just 'turn it into' the subclass, without any changes or re-running __init__. What I've done so far to accomplish this is something like:

from suds import WebFault

class MoreSpecificError(WebFault):
    # You pass the old WebFault when instantiating this exception.
    # Then it gets poofed into a MoreSpecificError type
    def __new__(cls, internal_fault):
        return internal_fault
    # This is necessary to prevent the parent class' __init__ from being run
    def __init__(self, internal_fault):
        pass

Edit: I now know this doesn't work, the new object will not be of the subclass' type

Which 'works', but the need to put that __init__ that's just a pass feels really gross to me. Not to mention some stuff doesn't like custom __new__ methods (read: deepcopy, it's not a choice, the testing framework we use (lettuce) uses it and we're pretty far invested already).

I'm wondering if there's a better way to do this? I know the ideal way is just to raise the subclass initially, but I'd really rather not start working with a forked copy of this library. I'm really hoping there's some magic somewhere in Python I just don't know yet.

ThisGuy
  • 2,661
  • 2
  • 18
  • 18
  • 1
    Your solution does not create an instance of your subclass. Returning `internal_fault` will return it as is, meaning it will still be an instance of the original class. Why do you not want to actually create a new exception instance normally (by running `__init__`, etc.)? – BrenBarn Oct 24 '14 at 19:37
  • oh damn, you're right, don't know where I got the idea `__new__` worked like that. But I don't want a new exception instance because I can't guarantee I get all the attached data copied over, I'm not the one that originally created or raised this exception and I don't want to break existing implementations. – ThisGuy Oct 24 '14 at 19:42

1 Answers1

1

I think this is what you're asking for:

class MoreSpecificError(WebFault):
    def __new__(self, old):
        old.__class__ = MoreSpecificError
        return old

However, it is risky for reasons described here. If all you are doing is catching the exception it should probably work, but no guarantees.

I still think it'd be better to just actually create a new exception object in the normal way. If you're worried about losing the information from the original exception, look in the documentation for that exception to see what information is documented to be part of its public API, and copy that information. Code that was relying on exception info that was not part of the original API is not something you need to support with your new API.

Community
  • 1
  • 1
BrenBarn
  • 242,874
  • 37
  • 412
  • 384
  • `Code that was relying on exception info that was not part of the original API is not something you need to support with your new API.` - I can get behind this. Sometimes I need a good dose of pragmatism from outside sources. – ThisGuy Oct 24 '14 at 19:52
  • I'm accepting this, but not because of the code provided (doesn't actually fulfill my needs since it still uses `__new__`). But because of the pragmatism in the last paragraph. – ThisGuy Oct 24 '14 at 20:31
  • @Conslo: Out of curiosity, why does using `__new__` not meet your needs? – BrenBarn Oct 25 '14 at 01:04
  • as stated before, our testing library uses `deepcopy()` internally, which doesn't like interacting with objects that impliment their own `__new__`: http://stackoverflow.com/questions/10618956/copy-deepcopy-raises-typeerror-on-objects-with-self-defined-new-method (there are several examples of questions like this). I *could* figure out how to properly implement my own `__copy__` and `__deepcopy__` to solve that, but that seems far too likely to be done wrong and cause bugs later. – ThisGuy Oct 28 '14 at 15:55