This line is added above the log function in order for the specs to pass.

A logger is needed for #log to be able to successfully run which the tests in exception_handler_spec.cr doesn't appear to have defined.

This shouldn't be a problem in the real world case as a logger would always exist afaik.

Please let me know if this should be rectified in some other way.

This approach won't work with inheritance.

What do you mean by inheritance in this case?

Calling .has_key? will check for the exception class only.

I suppose it should be something like Kemal.config.error_handlers.any?{ |key, _| ex.class <= key } in order to match subclasses of key as well.

That does identify whether the exception inherits from a known exception but shouldn't this also take into account the order of inheritance? For example

class GrandParentException < Exception
end

class ParentException < GrandParentException
end

class ChildException < ParentException
end

error Exception do
  "Generic" 
end

error GrandParentException do
  "Grandparent exception"
end

error ParentException do
  "Parent exception"
end

get "/" do
  raise ChildException.new()
end

I'll expect that the raised error in the above logic be caught by the handler for ParentException.

Is there any way of identify the order of inheritance at runtime?

Sure, you could sort classes by their inheritance relationship.

I don't think that would be a good idea though. Just following the order of declaration is probably best. rescue works the same way: the first matching branch wins, even if a later type would be a closer fit.

True. In that case I think this should achieve the desired behavior

suggestion: This special case with has_key? seems unnecessary because this is already covered with ex.class <= key.
It should be safe to remove this partial duplication.

thought: I'm wondering if it makes sense to mash up Int32 and Exception.class keys in a single hash.
Might be better to have two separate collections. They're used completely independent of each other. There's no need to expose both under the same name Kemal.error_handlers.
Maybe we could introduce a new name Kemal.exception_handlers for this feature?

performance: The combination of h.has_key?(key) and later h[key] is inefficient because it requires two hash lookups for the same key. Instead, you could directly query the value with h[key]? and use that as a condition. A nil return value would indicate the key does not exist.
Even better, you could already retrieve the handler while matching the exception (use each instead of each_key and you get the value for free) and pass it directly to this method. That removes two unnecessary hash lookups.