On 2017-06-23 23:56, Cameron Simpson wrote:
On 24Jun2017 05:02, Steven D'Aprano <steve@pearwood.info> wrote: [snip]
I think the concept of a "shallow exception" is ill-defined, and to the degree that it is defined, it is *dangerous*: a bug magnet waiting to strike.
What do you mean by "directly raised from the surface code"? Why is bah[5] "surface code" but foo(x) is not? But call a function (or method). [...]
I've replied to Paul Moore and suggested this definition as implementable and often useful:
A shallow catch would effectively need to mean "the exception's uppermost traceback frame refers to one of the program lines in the try/except suite". Which would work well for lists and other builtin types. And might be insufficient for a duck-type with python-coded dunder methods.
The target here is not perform magic but to have a useful tool to identify exceptions that arise fairly directly from the adjacent clode and not what it calls. Without writing cumbersome and fragile boilerplate to dig into an exception's traceback.
I think a "shallow exception" would be one that's part of a defined API, as distinct from one that is an artifact of the implementation, a leak in the abstraction. It's like when "raise ... from None" was introduced to help in those cases where you want to replace an exception that's a detail of the (current) internal implementation with one that's intended for the user.