Define error hints for abstract exception types

[gdalle]

Currently, it seems error hints have to be defined for a concrete exception type. Indeed, this line

julia/base/experimental.jl

Line 318 in 24d2f4a

hinters = get(_hint_handlers, typeof(ex), nothing)

only gets exception handlers for typeof(ex), and not for its supertypes. Would a PR be welcome to change that?

Concrete use case: I have recently added a common error supertype to Enzyme, in order to be able to define hints based on it inside DifferentiationInterface. However, no exception has the type Enzyme.Compiler.EnzymeError, they have concrete subtypes of that which may change between versions since they are internal details.

[timholy]

Presumably you might be able to replace

julia/base/experimental.jl

Line 319 in a4e02ca

isnothing(hinters) && return

with code that iterates up supertype(typeof(ex)) until you hit Any? Want to try a PR?

[gdalle]

At first I thought so, but we'd miss some UnionAlls along the way if an exception has a parametric type.

julia> struct MyException{T} <: Exception
           x::T
       end

julia> MyException in supertypes(MyException{Float64})
false

Any idea how to overcome that?

[vtjnash]

Two general options (that we use elsewhere in dispatch) is to iterate every possible hint handler and use subtyping and to shard the table based on the subtyping tree (such as jl_foreach_top_typename_for, which computes the typename of the topmost supertype which is not Function or Any) -- or just generally to key the table on typename instead of concrete type so that looking up each supertypes is sufficient, then iterate the list from there

[gdalle]

I think the fix PR is ready for review: #59843

[tecosaur]

While looping over supertypes work, this adds to my current impression that error hinting could be more neatly handled via dispatch.

Is that something that anybody else here might have opinions on?