In my recent iOS APP I am trying to connect SSL server with past date via AFNetworking. I am getting the error "The operation couldn't be completed. (NSURLErrorDomain error -1012)". I searched apple doc and found this error mean "NSURLErrorUserCancelledAuthentication" I need to show a more detailed error message on place of this High level message (NSURLErrorDomain error -1012). How can I convert this error code to more details string message. Should I need to do this my self (check error code and then show message accordingly) or Apple provide any other good way to show this message or is there any open source category or class available for the same. Already checked
Earlier I was interested in similar thing. But could not find anything useful. I think you have to do it yourself. There is not standard mapping from Error code to detail text.
You have to write a function yourself which may return text details from an error code.
The NSError instance itself provides the most detailed messages about an error, through methods such as localizedDescription.
You've hit up against a bit of a special case though, in NSURLErrorUserCancelledAuthentication. It should only be generated in response to your code cancelling an authentication challenge. i.e. by calling completionHandler(NSURLSessionAuthChallengeCancelAuthenticationChallenge, nil) or [challenge.sender cancelAuthenticationChallenge:challenge].
The framework figures that if a challenge has been cancelled, it's because the user asked to (and so there's no further UI to display), or your code chose to, and should display its own specific error info to the user.
Is there a bit of your code that is performing such a cancellation? Can you give us a bit more detail?
Related
I am working on a project that encounters a series of errors everyday such as user unsubscribed, etc. (About 4 or 5 different error codes everyday)
These errors are inconsequential to the management and can be ignored.
Any way to configure the alerts on Twilio to email me when any error occurs which DOES NOT belong to the error group that is deemed inconsequential?
Doesn't have to be email, new to this and open to any savvy ways of keeping myself informed of new errors in an automated way.
As far as I can tell, I can only perform the opposite action(Setup 1 alert for each error code) on the Twilio code. This has the disadvantage of having to know the error code in advance before configuring the alert.
Open to any way of doing this, not just through the console(via a Python API etc.)
Thank you.
Twilio developer evangelist here.
Can I suggest that you set up the event webhook as shown here:
It will send a webhook event to a server of yours for every error or warning that is triggered. You could then build a small service that receives those errors and discards the ones you don't care about and alerts you of ones that do matter.
On top of that, you can change the threshold of the error emails. If you always get 4-5 errors a day, making the alert threshold 6 errors may alert you if something is wrong that you don't expect.
Finally, the errors may be inconsequential, but you might find it easier to try to drive those errors to 0 every day anyway. If they are due to unsubscribed phone numbers, ensure to disable sending messages to those numbers once you detect that they are unsubscribed.
I'm trying to display a friendly message on the authentication failure prompt in Zapier. Throwing an Error or HaltedError is always showing the stack trace and the console logs which I'd like to get rid of. Is there a way to only display a custom message we specify?
Zapier has updated their UI recently. After "What happened", it now says, "You are seeing this because you are an admin". I take this to mean that the end users will not see the stack trace or console.
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 use Flurry 5.4.0 for iOS at the moment and I have a concern about being able to log more information than only an error ID when it comes to the method:
+ (void)logError:(NSString *)errorID message:(NSString *)message error:(NSError *)error;
You might wonder if I'm a bit slow, since there obviously exists a perfect parameter for just that, message:(NSString *)message. Well, unfortunately that message doesn't show up anywhere in the Flurry dashboard, which the Flurry Support Team confirmed in the answer that I got back (2014-08-30):
For error reporting, although you can pass the message in the logError function call - at the moment the dashboard doesn't have the provision to display the error message. This is something that is being considered in the long term feature road-map. Our product team is aware of this, and they would work on it, as a feature request. But, at the moment I do not have a time-line on if/when this would get implemented.
So, I don't really know how to proceed to add more important information "to" my errors. A first unsmart idea was to concatenate the information and send this in the first parameter:
errorID = errorID + errorMessage;
This to at least get the information to Flurry, but that would more or less always create unique error IDs and we would miss the great benefit of separating the errors into different kinds or errors. A really bad idea.
Apart from changing analytics provider I can't figure out a smart way to get hold of the own-created error information. Maybe I should just do that, or how do you add more useful error info to inspect at the Flurry dashboard?
Please feel free to speculate.
I asked the Flurry Team if I could get the message info from any of their ("requestable") open APIs instead and got this reply:
We do not have API that provides the error message. In addition to the errors section be sure to check the Technical -> Errors section. There is an exception log at the bottom that may provide some additional insight into the cause of your crashes.
When checking out the recommended section I found what I have been looking for. The message is located under the sub section called 'Exception Log'. I'd say that it's a bad placement, since it's more obvious to go look for logged errors under a section called 'Errors' than under 'Technical'. Right(?)
Flurry is a nice way to go so I would re frame what you define as an error and evaluate what is more important - getting the information back or getting it back as an error.
Option 1
I would log the events as some sort of sudo error (aka - "A bad thing happened" :) and use the parameters to bring back the additional details you are wanting.
Option 2
It was unclear in your response from the Flurry team if the information is completely unavailable or just not available within their portal/dashboard.
If you download the raw data from Flurry can you see the information you wanted and create your own dashboard as appropriate from that?
Hopefully this is enough speculation to get things flowing for you.
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!