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
There's no docs regarding the third argument usage on RestException. Initially I was overwriting Restler::message() so I could have custom error returns, including details manually - passing them through RestException made no difference. Later, when overwriting Compose (as per Document iCompose usage #522), I discovered how the third argument works: you must pass an array, that is going to be merged to the main error object. Sample: throw new RestException(404, 'Filters returned no results', ['details' => [$begin, $end]]).
There's no docs as well about custom error handling classes. I stumbled upon them in the source, just like it happened with the point above. However, I'm still not sure how to deal with them in my case at least, since my API classes might throw database exceptions, and I would like to catch them and turn into RestException instances (such as ModelNotFound = 404, InvalidModelException = 422, etc).
Discussion: would it be clearer if the third argument was appended as "details" instead of merged? This way we would not need to specify keys (or even an array, as it is now), and it would make for more standardized APIs (always with error + message + (optional) details).
The text was updated successfully, but these errors were encountered:
RestException
. Initially I was overwritingRestler::message()
so I could have custom error returns, including details manually - passing them through RestException made no difference. Later, when overwritingCompose
(as per Document iCompose usage #522), I discovered how the third argument works: you must pass an array, that is going to be merged to the main error object. Sample:throw new RestException(404, 'Filters returned no results', ['details' => [$begin, $end]])
.RestException
instances (such asModelNotFound
= 404,InvalidModelException
= 422, etc).Discussion: would it be clearer if the third argument was appended as "details" instead of merged? This way we would not need to specify keys (or even an array, as it is now), and it would make for more standardized APIs (always with
error
+message
+ (optional)details
).The text was updated successfully, but these errors were encountered: