Add ability to add handlers for raised exceptions

[syeopite]

Closes #622

Description of the Change

This PR adds the ability for users to define error handlers that are used when a specific exception is raised.

require "kemal"

class NewException < Exception
end

get "/" do | env |
  raise NewException.new()
end

error NewException do | env |
  "An error occured!"
end

Kemal.run

Alternate Designs

Benefits

This provides for a cleaner and easier experience for defining custom errors. See #622.

Possible Drawbacks

[syeopite]

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.

[robacarp]

This is perfect!

[Sija]

This approach won't work with inheritance.

[syeopite]

What do you mean by inheritance in this case?

[Sija]

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

[straight-shoota]

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.

[syeopite]

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?

[straight-shoota]

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.

[syeopite]

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

[straight-shoota]

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.

Suggested change

	# Use error handler defined for the current exception if it exists
	return call_exception_with_exception(context, ex, 500) if Kemal.config.error_handlers.has_key?(ex.class)

[straight-shoota]

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?

[straight-shoota]

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.