You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice to actually have the Exception and Error Routes be treated the same as all other types or Route objects. Instead what happens is the minute there's an exception, all of the accept() routine functionality is completely ignored and a call is made to these handlers that just spits that content out as is without any regard to the Accept header. This breaks parsers that are expecting valid content responses.
On top of this issue, if you return an empty string to try to at least prevent the parsing issues without giving any detail to the cause, it still breaks. It appears that the Request object is doing lazy comparisons with what was returned from the Exception handler and if it's an empty value, it assumes that the handler failed and then rethrows the exception.
This is basically a deal breaker since my choice is to not handle exceptions and have the API break entirely, or return non valid content results and have the API parsers break on the client side. Both completely unacceptable.
The text was updated successfully, but these errors were encountered:
It would be nice to actually have the Exception and Error Routes be treated the same as all other types or Route objects. Instead what happens is the minute there's an exception, all of the accept() routine functionality is completely ignored and a call is made to these handlers that just spits that content out as is without any regard to the Accept header. This breaks parsers that are expecting valid content responses.
On top of this issue, if you return an empty string to try to at least prevent the parsing issues without giving any detail to the cause, it still breaks. It appears that the Request object is doing lazy comparisons with what was returned from the Exception handler and if it's an empty value, it assumes that the handler failed and then rethrows the exception.
This is basically a deal breaker since my choice is to not handle exceptions and have the API break entirely, or return non valid content results and have the API parsers break on the client side. Both completely unacceptable.
The text was updated successfully, but these errors were encountered: