I've been trying to send some additional information on the validation errors returned by the server-side SaveChanges method but breeze-client is parsing these errors and takes only the properties that the library is interested in. Is there a way to work around this behavior?
Kindly implemented by #SteveSchmitt in #42
Related
I've got my basic CloudKit sync engine built and working correctly and I now I am fleshing out my error handling. I'd like a comprehensive list of which errors are possible per record when you receive a .partialFailure response code.
The documentation has a list of all the error codes, but in my searching it hasn't been obvious (to me) which are potentially going to show up inside the partialErrorsByItemID dictionary and which are going to show up only as error codes (or if they can show up as both, maybe when sending only one record?).
In the Apple CloudKit Share code example there is a CloudKitError class to handle errors, and that handles the following partial errors:
.serverRecordChanged
.zoneNotFound
.unknownItem
.batchRequestFailed
but I don't believe that is exhaustive as the rest of the class isn't exhaustive in handling errors that aren't .partialFailure. Surely .invalidArguments would be a possible partial failure error?
Here's what I would guess I need to cover:
.alreadyShared (if sharing)
.assetFileModified (if using Assets)
.assetFileNotFound (if using Assets)
.batchRequestFailed
.constraintViolation
.invalidArguments
.referenceViolation (if sharing)
.serverRecordChanged
.unknownItem
.zoneBusy?
.zoneNotFound
And finally, because these are handled as partial errors, do I also need to handle them as possible error code responses from CloudKit, in the same way I handle non-partial error codes like .serviceUnavailable? I am not using the CKDatabase convenience methods, I'm using the full operations like CKModifyRecordsOperation, if that matters?
Thanks in advance!
In CloudKit, you have convenience API and Batch Operations API. If you are only using the convenience API in your app, this means that you add/update/fetch/delete a single record at a time. Thus, you will never get CKErrorPartialFailure because you are NOT communicating with iCloud Server in batches. If you are using only Batch Operations API in your app, then you will get CKErrorPartialFailure. It is a high-level error that actually contains a sub-error (CKError instance) for each record/zone/subscription included in your operation.
I agree with you that the documentation is not clear what could occur only as a partial error and what could not. Plus what could occur in either case. To answer this question, you can take a simple approach by assuming that all errors might occur in both cases or you either another more detailed oriented approach by finding out the possible cases for each error.
For the second approach, I had to simulate different error scenarios and see which errors I get from the iCloud server. Please take the following points into consideration:
Try as many CKOperation as you can to get list of errors. You have operations for records, zones, database, subscriptions.
Is the operation atomic or not?
Some errors are impossible to simulate because we don't control iCloud Server responses by any means. Example: CKInternalError, CKServerRejectedRequest
Some errors would only occur during Development phase and should not occur during Production phase. Example: CKBadContainer,CKMissingEntitlement,CKBadDatabase
Some errors are clearly non-partial errors because they are more related to the whole request sent to iCloud. Examples: CKIncompatibleVersion, CKServiceUnavailable, CKRequestRateLimited, CKOperationCancelled, CKLimitExceeded, CKServerResponseLost, CKManagedAccountRestricted
Some errors can only occur as partial errors. Example CKBatchRequestFailed. This one only occur for atomic CKOperations
Some errors can occur as both partial/non-partial errors. Examples: CKNotAuthenticated, CKNetworkUnavailable, CKNetworkFailure. They occur as a partial error for record zone operations while they occur as non-partial error for records operations.
Some Zone related errors will appear as partial errors when using Batch Operations API. Examples:CKUserDeletedZone , CKZoneBusy. Exception: CKChangeTokenExpired I got it as a non-partial error when I was performing an operation-based call.
CKZoneNotFound occurs as a partial and non-partial error. If you use CKModifyRecordsOperation to upload to a non-existing zone, you will get a partial error. However, if you use CKFetchRecordZoneChanges to fetch from a non-existing zone, you will get non-partial error.
Merge Conflicts errors occur as a partial error when using Batch Operations API.
In WWDC 2015 Video, CKInvalidArguments was mentioned as one of the errors that might occur as partial error when using Batch Operations API. However, I tried different error scenarios (such as: creating/updating a record in the same request) and it occurs as a non-partial error. So to be in the safe side, I might handle it for both partial and non-partial errors.
CKQuotaExceeded occurs as a non partial error. I managed to reproduce that error by filling my iCloud storage by data from different apps except Photos. Backup will fill most of the storage then it won't be hard to fill in the rest of the available space.
CKUnkownItem occurs as a non-partial error when using convenience API. Also occurs as a partial error when using Batch Operation API.
All the sharing/assets related-errors, I am not familiar with them but I think the relative ones that you listed in your question, are good to be considered as partial errors.
I am new to Relay and am working on a small project using react-relay/classic with react-router-relay. I am trying to decide the best way to implement simple error handling for the case where a query fails.
I am just looking for a "catch all" system which will allow me to tell the user that it looks like they're not online. Nothing more complex is required.
From the Relay documentation, it looks like the regular relay way to do this would be with the renderFailure prop on Relay.RootContainer. However, as I am using react-router-relay I never create a Relay.RootContainer directly - it looks like these are created under-the-hood by react-router-relay.
I haven't been able to find anything in react-router-relay documentation about how to access the underlying Relay.RootContainer props, or on error handling. I have also had a quick look at the source code and nothing obvious jumps out.
So my question is: is there any way I catch query failures when using react-router-relay?
I'm writing a login sequence for an iOS app and I'm using the following path to request user information:
"profiles/:email" (RKRequestMethodGET)
Unfortunately I also have to use this path to check if a certain e-mail address has already been taken as well.
My question is, how do I prevent RestKit from updating/inserting an Account object into the Managed Object Store when I already have an Entity Response Mapping in place for that path? Is there a way to tell the RK request that is shouldn't do any mapping to the Managed Object Store but still report back to me that a successful mapping has occurred?
Not really.
You could have 2 different RKObjectManager instances, 1 that is used for Core Data and actually updating and managing the users. The other is used without Core Data and just for validation. This allows the 2 different object managers to have different response descriptors.
An alternative would be to add and remove the response descriptors depending on what requests you're making. But, this is messy and potentially error prone.
I have a general question- what are some guidelines for handling NSError's? For instance, NSJSONSerialization can return an error creating JSON objects or JSON data.
I feel like it's (maybe) not appropriate to alert the user in this case? But the error message is still important.
So I'm not sure when and where the best place to handle obscure, non-user related errors?
This totally depends on the context in which error is thrown.
Per Apple Documentation:
Recover if Possible or Display the Error to the User
The best user experience is for your app to recover transparently from
an error. If you’re making a remote web request, for example, you
might try making the request again with a different server.
Alternatively, you might need to request additional information from
the user such as valid username or password credentials before trying
again.
So, there are cases, where you would want error to be obscured from user with potential fall back on error recovery path.
And there are cases, where you would want to let user know of the error occurred and take a corrective measure.
At the same time, in many situations, as a programmer we want to log error on console so we could fix them while testing.
As a side note, there are plenty of cases where we throw custom NSError objects and handle them with alerts, logging or other ways!
It is worth going through the shared Apple Documentation link, I believe!
ASP.Net MVC 3, Kendo UI Web.
Typical example -- there is a database and some tables, user is editing the data -- adding new entries, deleting, updating.
Apart from technical problems (network connection down), there could be several logical ones -- for example user does not have permission to write anything, or there is a lock on data, or user tries to update something what was deleted meanwhile, and so on.
So I would like to return in such cases an error, so I could handle it with Kendo and display, let's say some alert dialog (JS alert).
Now -- what would be the most well designed way, most correct, to do so? I am not looking for "oh, well, it just works" approach.
Is throwing HttpException a good idea in such case (I have my issues with it, because it is http exception, and the error I try to pass has nothing to do with http really)?
I'm going to work under assumption that you're using Kendo DataSource object which exists on most widgets in self-binding mode (has transport section defined and fires it's own CRUD requests).
The actions that your grid's CRUD is tied to, should be returning IEnumerable.ToDataSourceResult, on the model it received as input. If in your processing you detected errors, add them to ModelState via ModelState.AddModelError method which you can access in your action. The ToDataSourceResult will detect presense of any errors in ModelState object automatically and serialize them into the JSON response (errors field). You can then act on them via subscribing to DataSource.error even on the client side (see http://docs.kendoui.com/api/framework/datasource#error).