Errors caused by invalid body content are not processed by rescue handlers

[croeck]

Hi all,

I ran into a more or less severe issue today. I am running grape directly behind rack (NO rails) and found an issue that has also been described in issue #389, which however was run behind rails.

Here is the problem:
If I fire a request against my API with the body set to an random non-JSON value, for instance simply test, the MultiJson parser returns an MultiJson::ParserError error with the message 795: unexpected token at 'test' that occurs in the Grape::Middleware::Formatter and is then thrown as 400 response message.

What I would expect is that my rescue_all handler gets notified of the error and can handle the situation. Instead, Grape::Middleware::Error.call catches the thrown error, which then gets processed in the Grape::ErrorFormatter::Base.

In there, two lines (actual comments) perfectly explain the next issue:

 # env['api.endpoint'].route does not work when the error occurs within a middleware
 # the Endpoint does not have a valid env at this moment

Ok, so there the call crashes again and raises a NoMethodError. This error then finally gets processed by my rescue_all handler. Nevertheless I receive a response with the status 500 instead of the actual expected 400.

Even if the exception in the Grape::ErrorFormatter::Base would be prevented, the call would not reach the rescue handlers.

In my opinion the rescue handlers should get a chance to handle the error since it is directly related to the request body.

If a have some spare time I'll try to write a spec for the issue in the next couple of days.

[croeck]

Ok, I wrote a small spec and found out that the issue is related to the content type definition that is sent by the user. When specifying application/json, the request fails. But when no content type is specified, the request is processed and fails (as expected) because of the missing param.

[dblock]

It's definitely a problem, would love it to see this fixed.

[croeck]

I updated the pull-request #906 and added a possible solution how to handle the parsing errors. It shows that I catch the error and raise a new InvalidMessageBody, which by default translates into a 400 and can be processed by any rescue handler (see included spec).

[dm1try]

Fixed in #906