Benjamin Risher <brisher...@gmail.com> writes:
> Ok, here's my issue.  I have a plugin framework I wrote that relies on a 
> third party library that I can't change.  As a part of that framework, I 
> wrote a small stub library to proxy calls to the third party library, so that 
> if their api ever changes, plugins written against the stub won't have to 
> change, I'll just have to update the back-half that interfaces with the 
> library.  I think this is called an adapter design pattern...?  
>
> plugin --> my api --> their api --> their library 
>
> It works, for the most part.  Most of my classes look similar to this
>
>     class MYClass:
>         def __init__(self, *args, **kwargs):
>             self.__theirclass = TheirClass(*args, **kwargs)
>
>         def __getattr__(self, attr):
>             return getattr(self.__theirclass, attr)
>
> What I'm having issue with, is their exception class.  
>
> 1.  A plugin calls a stub in my library
> 2.  That stub calls the corresponding call in the third party library
> 3.  The call raises an exception from the library
> 4.  The plugin can't catch the exception without importing directly from the 
> third party library
>
> What is the correct way to allow plugins to import my stub exception, but 
> catch the ones raised by the library?

I would approach this as follows:

 * define an exception hiearchy for your wrapper with a common root class
   and document those hiearchy to be used for the plugins

 * in your wrapper, catch all exceptions

   - if it is one of your execptions, you know what to do

   - if it is a general Python exception, it likely indicates
     a programming error in the plugin or library -- handle
     as appropriately (personally, I would "reraise")

   - if it is something else, it likely indicates that
     the plugin violated its contract (towards your wrapper API) --
     handle as appropriate (again, I would "reraise").

-- 
https://mail.python.org/mailman/listinfo/python-list

Reply via email to