Question: clarity on subclassing from rescue_registry vs graphiti-rails

[jasonkarns]

I have to admit, I'm a bit confused about the current state of exception handling between graphiti_errors, rescue_registry, and graphiti-rails.

As best as I can tell, graphiti_errors is essentially deprecated. rescue_registry is where I should be looking for things, and graphiti-rails has already switched to use rescue_registry.

My current question is which class I should be subclassing for my custom exception handler. I am in a Rails app and using graphiti-rails; so my natural inclination is to subclass Graphiti::Rails::ExceptionHandler. However, I'm a bit surprised that ApplicationController.default_exception_handler is an instance of RescueRegistry::ExceptionHandler. I would have expected that graphiti-rails would have made the default handler use Graphiti::Rails::ExceptionHandler.

So now that I'm creating my own custom handler, I want to diverge from the default handler as little as possible. Which has me unsure which one I should actually subclass. Truth be told, I'm not even entirely clear what Graphiti::Rails::ExceptionHandler even does over RescueRegistry::ExceptionHandler.

Any guidance?

[richmolj]

Yeah it's definitely confusing. Some context here: graphiti_errors used rescue_from to catch and handle errors, but then we got complaints things like bugsnag/newrelic middleware weren't working because we caught the error before they could handle it.

Now the code is refactored so we do the error handling later on in the process and middleware works, but this involves hooking into some confusing semi-public Rails internals. And thus came RR and the graphiti-rails tie-ins, and some documentation we probably forgot to update.

RR is the higher-level "outer" lib here and is thus the default handler (IOW you could use it independent of Graphiti). Graphiti itself hooks in via graphiti-rails here, using RR to apply our default handlers.

You want to subclass Graphiti::Rails::ExceptionHandler, which contains stuff like this that you expect to get from Graphiti. But RR at a higher-level allows us to use the same pattern (registering errors and responding with config-based json) independent of Graphiti.

I think the issue here is mostly documentation, but also some inherent complexity in handling errors this way.

I think graphiti_errors is mostly used for validation errors at this point. If we can get a list of places where docs need to improve, all ears!

[jasonkarns]

Thanks for clarifying. This docs PR graphiti-api/graphiti-api.github.io#45 is directly related.

Some other improvements I would suggest would be replacing the references to :message option in favor of :detail, which, as I understand it, is now preferred.

https://github.com/graphiti-api/graphiti-api.github.io/blob/5e0abae076f8ecafe5c5d82abc3fc4cd997e2493/guides/concepts/error-handling.md?plain=1#L40

and

https://github.com/graphiti-api/graphiti-api.github.io/blob/5e0abae076f8ecafe5c5d82abc3fc4cd997e2493/guides/concepts/error-handling.md?plain=1#L114-L115

which should also call out detail: :exception instead of message: true?

In fact, I'll just PR this momentarily.