-
Notifications
You must be signed in to change notification settings - Fork 7
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
CloudCreativity\JsonApi\Error\ErrorObject toArray() enhancement? #14
Comments
Good point - I hadn't spotted this because I'm not using them in this way, but you're totally right that it shouldn't return null values. I'll get this fixed. |
Have just realised this isn't a bug. If you're using the So your code should look like this: $error = new ErrorObject([
'status' => '418',
'code' => '1',
'title' => "I'm an error object",
'detail' => 'error object',
'meta' => ['render' => 'form'],
]);
throw new ErrorException($error); When error objects are rendered, Internally within Does that make sense? The thing I could add if it would be useful is to add a |
Howdy @lindyhopchris! Thanks for being so diligent about this... I guess I was trying not to use exception throwing for app logic errors but I'm not opposed to the idea of using the existing ErrorObject in combination with a helper method such as the one you mentioned (yes I know ultimately there'd be an exception throwing but I can live with it :P). Please do add the helper!! :D I really like both packages you've built to handle json-api and I expect to continue using them a lot in the future. Closed as it's currently possible to go around the issue by using ErrorObject and ErrorException to create a valid JSON API response. |
Great. Glad you like the packages and keep sending me an ideas/issues! I've created an issue in the |
Could it be possible to have the toArray() method (in
CloudCreativity\JsonApi\Error\ErrorObject
line 332) return only not null values?I'll try to explain my scenario. I wanna be able to use this class to build application logic errors (as opposed to an Exception which handles "exceptional" situations) that I can then use to respond a client with using the following syntax:
Currently if I do it like that, I get the following response:
I'd rather not have all the null value keys returned from toArray(). Would implement such behavour break in some way the functionality of the class?
The text was updated successfully, but these errors were encountered: