The catch is, that leaves the host system unaware of the exception. Since the exception was caught it doesn't bubble up to the parent system to be caught by it's error handling system.
From what I understand, it's also not possible to both render a response and raise an exception.
What if, we expose the ability to configure a "callable" in an initializer that will be called with the given exception in the event that one is rescued?
For example, the proc could be a call to Honeybadger:
# In host app initializer
ScimRails.configure do |config|
config.error_handler = -> (e){ Honeybadger.notify(e) }
end
By default, we could potentially make it a call to the rails logger so that "silence" is not the default:
Currently in the code, we rescue all exceptions and provide a custom JSON response for the 500 error: https://github.com/lessonly/scim_rails/blob/a38f7be164257a46af4878acde3e062b6e3107a4/app/controllers/concerns/scim_rails/exception_handler.rb#L20-L28
The catch is, that leaves the host system unaware of the exception. Since the exception was caught it doesn't bubble up to the parent system to be caught by it's error handling system.
From what I understand, it's also not possible to both render a response and raise an exception.
What if, we expose the ability to configure a "callable" in an initializer that will be called with the given exception in the event that one is rescued?
For example, the proc could be a call to Honeybadger:
By default, we could potentially make it a call to the rails logger so that "silence" is not the default: