-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exception handling #45
Comments
I'm not totally sure what you're missing but you should get both of those out of the both. FWIW the way Graphiti works you shouldn't ever be raising that error, we instead raise |
Thanks. In my situation I'm not raising the exception, Rails does when I look for the record. I look for it before rendering the response for the purpose of authorization, then if I don't find it, I would like to respond with legal jsonapi errors. I couldn't find |
Ok, found |
You have to make sure that |
I was having trouble getting errors to be rescued and the reason seems to be the following configuration setting:
That's the default value in the It seems like I want the setting as is in test, but that means I can't test the Graphiti error responses. Is my analysis accurate? Any suggestions? |
This is the same as in our sample app which is not having problems. So a good place to look is the difference in configuration between your app and the sample app. Might also want to check https://github.com/graphiti-api/graphiti-rails#debug-exception-format |
Thanks for the quick feedback. The sample repo does not have any tests around error handling. I added the following tests to context 'with invalid age' do
let(:payload) do
{
data: {
type: 'employees',
attributes: {
age: 'Forty Two'
}
}
}
end
it 'does not handle error when show exceptions is false' do
expect { make_request }.to raise_exception(Graphiti::Errors::InvalidRequest)
end
context 'with helper that sets show exceptions to true' do
it 'handles error' do
handle_request_exceptions do
expect { make_request }.not_to raise_exception
end
end
end
end It also shows that the helper I don't have permission, otherwise I'd be happy to push up the branch with the tests. |
Ah, I see, thanks for the sample code - I think this is where we were missing each other, right? https://www.graphiti.dev/guides/concepts/error-handling#testing |
When I read that the first time, I didn't grasp the full meaning. I think the disconnect for me might be that I assumed that this would handle errors the same way rails does. Going back to my initial question, the answer seems to be that you do have to set Probably yet another reason to keep controllers simple and find a direct way to test. (I'm a big fan of the resource specs.) As feedback, I'm leaning towards just using |
Could someone provide a more detailed explanation of the way exception handling works? I added
to my controller, but it does not seem to be caught. I stepped into it and verified that it is added to a list of handled exceptions, but couldn't find what I need to do for these to actually be rescued.
I previously used
rescue_from
, and don't mind using it again, but I would need to produce a standard jsonapi response, and couldn't find a method (in eithergraphiti
orgraphiti-rails
) that would do that. Also couldn't find something that convertsobject.errors
to such a format. I assume I'm missing something fundamental...The text was updated successfully, but these errors were encountered: