Best practice for handling exceptions raised at lower levels?

[Terry Reedy]

On 2/1/2021 7:54 PM, Skip Montanaro wrote:

> However... Network applications being what they are, hiccups are going
> to happen. In the time since I swapped in the imapclient package, I've
> also had to catch exceptions raised by lower level modules/packages I
> wasn't using directly, discovering them only as they occurred. (Think
> of it as lazy exception discovery. I suppose if I was developing the
> application for others, I'd have been more proactive about uncovering
> the exceptions.) In addition to a couple imapclient exceptions, I also
> now need to catch socket.gaierror, ConnectionError and
> imaplib.IMAP4.error.
> 
> Here's the crux of the problem. Where does responsibility generally
> fall for low level exception handling?

The general advice on this list is 'Only catch exceptions you can 
usefully do something with'.  Some things are clear.  Any code calling 
next(it) should catch possible StopIteration.  Library code, like 
IMAPClient, should not catch BaseException and reraise SystemExit. 
Other times, 'useful' is not so clear.

> I don't mean to pick on IMAPClient. 

It's pypi page https://pypi.org/project/IMAPClient/
has author and maintainer email links.  You can ask them what their 
intention is in regard to dependency exceptions.  Their feature list 
includes "Exceptions are raised when errors occur."  Does this include 
letting the exceptions you mention, and others, pass through?  Do you 
think their doc should be any clearer than it is?

I think responsibility partly depends on whether a particular low level 
exception is a flow control exception or bug exception, and if the 
latter, in whose code.

> It's just a recent example and got me thinking about the
> problem. Is it (generally) the responsibility of the application
> author or the package author? This isn't an issue just for network
> applications with a number of moving parts (socket, ssl, higher level
> packages, etc). It happens in almost all applications or packages,
> even if it's just to deal with exceptions raised by internal data
> structures.


-- 
Terry Jan Reedy