How do you find what exceptions a class can throw?

[2QdxY4RzWzUUiLuE at potatochowder.com]

On 2020-12-20 at 18:25:40 -0000,
Grant Edwards <grant.b.edwards at gmail.com> wrote:

> On 2020-12-20, 2QdxY4RzWzUUiLuE at potatochowder.com <2QdxY4RzWzUUiLuE at potatochowder.com> wrote:
> > Chris Green <cl at isbd.net> wrote:
> >
> >>>   Ultimately, it is not possible to tell what exceptions 
> >>>   a call might throw.
> 
> While it may not be "ultimately possible", in practice it usually
> is. Most libarary documentation lists exceptions thrown by fuctions
> and explains what causes them.
> 
> >>>   In such a case, it may help to explain
> >>>   to the newsgroup why this information is needed.
> >>
> >> So that, as is always advised, I can catch the specific exception
> >> being thrown!
> >
> > To the point: what are you going to do with it once you catch it?
> 
> Seriously? You've never written code that handled an exception?

No.  Of course I've written code that catches exceptions.

Have you ever written code that ignored an exception, explicitly or
implicitly?  Of course you have.

My point was to get the OP to think about *handling* exceptions, not
just catching them because a library function throws them, or trying to
deal with everything that might happen in the future.

> > Are you prepared to handle every exception individually,
> 
> Of course he isn't.

How do we know that?

> > or are you fishing for exceptions that you think might be worth
> > catching?
> 
> You handle whatever exception(s) you expect, and let the others pass
> up to higher levels. There are lots of cases where there may be one or
> two exceptions that you want to handle.

Subsequent emails indicate that Chris Green does as well, but it took a
while to get there (or perhaps I just misunderstood all those vague
references to catching exceptions).

> > Remember, you get reporting (a traceback) and program cleanup and
> > exit for free.  What will catching an exception *add* to the user
> > experience?
> 
> Yes, if you can deal with it in such a way that normal execution of
> the program (from the user's POV) continues. Exceptions aren't always
> bugs and errors. Sometimes it's just an uncommon use-case that is
> foreseen and dealt with.

Agreed.  Some programs recover from and continue under (for their own
definitions of "recover" and "continue") horrendous conditions, other
programs dump a traceback and let a user/operator/customer deal with it.
Chris Green gave little or no indication of expectations or desires.