What is `NSLocalizedFailureErrorKey` for? - ios

Among the well-documented strings NSLocalizedDescriptionKey, NSLocalizedFailureReasonErrorKey, NSLocalizedRecoveryOptionsErrorKey, and NSLocalizedRecoverySuggestionErrorKey there is also NSLocalizedFailureErrorKey, which lacks any kind of description in documentation. What is it for?

From the header:
FOUNDATION_EXPORT NSErrorUserInfoKey const NSLocalizedFailureErrorKey API_AVAILABLE(macos(10.13), ios(11.0), watchos(4.0), tvos(11.0));
// NSString
A complete sentence (or more) describing what failed. Setting a value for this key in userInfo dictionary of errors received from framework APIs is a good way to customize and fine tune the localizedDescription of an NSError.
As an example, for Foundation error code NSFileWriteOutOfSpaceError, setting the value of this key to "The image library could not be saved." will allow the localizedDescription of the error to come out as "The image library could not be saved. The volume Macintosh HD is out of space." rather than the default (say) “You can't save the file ImgDatabaseV2 because the volume Macintosh HD is out of space."

Related

Crash when using error.localizedDescription from completion

I'm trying to check if error.localizedDescription contains a certain string but i keep getting a crash
if error.localizedDescription.contains("\"api.error.cardRejected.2000\"") {
failCompletion()
}
I have even tried to even use another way
if let description = (error! as NSError).userInfo[NSLocalizedDescriptionKey] as? String {
if description.contains("api.error.cardRejected.2000") {
failCompletion()
}
}
I still keep getting the same crash in the logs saying
-[__NSDictionaryM domain]: unrecognized selector sent to instance 0x60000046b520
It works when i check using the debugDescription but i would like to check using the localizedDecription since the debug one only works when debugging
NSError localized description is autogenerated from what's inside, here is what API tells:
/* The primary user-presentable message for the error, for instance for NSFileReadNoPermissionError: "The file "File Name" couldn't be opened because you don't have permission to view it.". This message should ideally indicate what failed and why it failed. This value either comes from NSLocalizedDescriptionKey, or NSLocalizedFailureErrorKey+NSLocalizedFailureReasonErrorKey, or NSLocalizedFailureErrorKey. The steps this takes to construct the description include:
1. Look for NSLocalizedDescriptionKey in userInfo, use value as-is if present.
2. Look for NSLocalizedFailureErrorKey in userInfo. If present, use, combining with value for NSLocalizedFailureReasonErrorKey if available.
3. Fetch NSLocalizedDescriptionKey from userInfoValueProvider, use value as-is if present.
4. Fetch NSLocalizedFailureErrorKey from userInfoValueProvider. If present, use, combining with value for NSLocalizedFailureReasonErrorKey if available.
5. Look for NSLocalizedFailureReasonErrorKey in userInfo or from userInfoValueProvider; combine with generic "Operation failed" message.
6. Last resort localized but barely-presentable string manufactured from domain and code. The result is never nil.
*/
open var localizedDescription: String { get }
so, it is crashed (probably at step 6.) then this NSError is incorrectly constructed - so find who & how constructed it, possibly at some layer on underlying errors some key of userInfo unexpectedly is set as NSDictionary instead of NSError.

iCloud sync fails with "CoreData: Ubiquity: Invalid option: the value for NSPersistentStoreUbiquitousContentNameKey should not contain periods"

CoreData: Ubiquity: Invalid option: the value for NSPersistentStoreUbiquitousContentNameKey should not contain periods: com.YashwantChauhan.Outis
-PFUbiquitySwitchboardEntryMetadata setUseLocalStorage:: CoreData: Ubiquity: mobile~20BF44C9-C39F-48DC-A8A1-B45FC82C7E20:com.YashwantChauhan.Outis
I have a problem with syncing with iCloud. These two errors above are thrown at me. I don't know what's the problem, I setup the Entitlements file, and set the Ubiquity Container to com.YashwantChauhan.Outis.
I start the CoreData stack using MagicalRecord's method:
[MagicalRecord setupCoreDataStackWithiCloudContainer:#"N6TU2CB323.com.YashwantChauhan.Outis" localStoreNamed:#"Model.sqlite"];
But that shouldn't even matter since MagicalRecord just simplifies CoreData methods.
Help much appreciated.
Ok update:
-[NSFileManager URLForUbiquityContainerIdentifier:]: An error occurred while getting ubiquity container URL: Error
Domain=LibrarianErrorDomain Code=11 "The operation couldn’t be
completed. (LibrarianErrorDomain error 11 - The requested container
identifier is not permitted by the client's
com.apple.developer.ubiquity-container-identifiers entitlement.)"
UserInfo=0x15e0d8a0 {NSDescription=The requested container identifier
is not permitted by the client's
com.apple.developer.ubiquity-container-identifiers entitlement.}
This is the latest error message I got, I realize this differs from the question's initial error but it so turns out that the old message was some kind of strange bug of sorts. I tried #Rauru Ferro's solution by removing the periods from my Ubiquity Container identifier. I knew that this wouldn't work because the requirements for the identifier is to contain periods, but then when I put the periods back in, it spat the error message above. Which makes more a lot more sense than not using periods. We all know that we do.
I also found this handy code snippet that can actually checks my Ubiquity Container identifier by fetching it. Useful snippet to quickly check if you have any problems with it.
NSString *containerId = #"com.YashwantChauhan.Outis";
NSFileManager *fileManager = [NSFileManager defaultManager];
NSURL *iCloudURL = [fileManager URLForUbiquityContainerIdentifier:containerId];
NSLog(#"%#", [iCloudURL absoluteString]);
Another update: By the looks of it, this stupid NSPersistentStoreUbiquitousContentNameKey should not contain periods is a whole mess. If NSPersistentStoreUbiquitousContentNameKey is created like some kind of folder (Tutorial), then the requirement is that there is no . infront of the name, like .com.YashwantChauhan.Outis but that is not the case. I am starting to go mad here! There is no problem with the Entitlements file and there is nothing with fetching the iCloud container ID in MagicalRecord. I am starting to think this is an internal problem with setting up iCloud in Xcode 5, but of course I don't know. With this said, I might just be loosing my mind over something trivial or something that will actually cause a headache for other people.
Can anybody post their Entitlements file so I can verify how an actual working version looks like. Redacted of course. Thank you!
refer
https://forums.pragprog.com/forums/252/topics/12315
Quoting the response:
This was changed recently (Mavericks). Fortunately for you, since you are just now adding iCloud, the impact is minimal.
You need to change the following line of code:
[options setValue:[[NSBundle mainBundle] bundleIdentifier] forKey:NSPersistentStoreUbiquitousContentNameKey];
To something else. What is that something else? I would recommend something descriptive to your application. I have been using class name like structures recently. So I would change it to be the name of your app perhaps or simply “DataStorage”.
The name is unique to your application so the actual value is not important as long as it is understood by you.
So I changed my code below...
options = [NSDictionary dictionaryWithObjectsAndKeys:
[NSNumber numberWithBool:YES], NSMigratePersistentStoresAutomaticallyOption, // Key to automatically attempt to migrate versioned stores
[NSNumber numberWithBool:YES], NSInferMappingModelAutomaticallyOption, // Key to attempt to create the mapping model automatically
#"TrafficCamNZ_DataStore", NSPersistentStoreUbiquitousContentNameKey, // Option to specify that a persistent store has a given name in ubiquity.
cloudURL, NSPersistentStoreUbiquitousContentURLKey, // Option to specify the log path to use for ubiquitous content logs.
nil];
Refer the line that says TrafficCamNZ_DataStore
it previously had TrafficCamNZ.DataStore
David
I am using a shared container and just had the same error warning popping up. I could fix it by replacing all occurrences of varying cloud identifier strings like:
"$(TeamIdentifierPrefix)com.mydomain.myapp" and
"com.mydomain.myapp" and
"ABCDEF0123.com.mydomain.myapp"
with just this one explicit cloud container string:
"ABCDEF0123.com.mydomain.myapp"
I guess that at some point, Xcode must have updated the entitlements and re-inserted the "$(TeamIdentifierPrefix)", which was wrong due to the shared container. Also, I had forgotten the identifer in code, just like you seemed to have:
NSString *containerId = #"com.YashwantChauhan.Outis";
that should probably be something like:
NSString *containerId = #"ABCDEF01234.com.YashwantChauhan.Outis";
I had the same issue and I am not sure what the issue is or why it is there.
From what I am reading we should be able to use the dots in the containerId.
However, for me it started working by replacing the dots in the containerId with tildes:
i.e.:
NSString *containerId = #"N6TU2CB323~com~YashwantChauhan~Outis";
instead of:
NSString *containerId = #"N6TU2CB323.com.YashwantChauhan.Outis";
Try to use comYashwantChauhanOutis, without the two points.

FILE-ACCESS Reading images previously written to NSDocumentDirectory FAILS

Having recently downloaded and installed XCode 4.3 from the App Store, I find a serious and unexpected problem when reading image-files (large JPEG files) previously stored in the application User Documents. The issue is as follows:
(i) The files derive from the user's photo-library and the UIcropped original image ( UIImagePickerControllerOriginalImage) is correctly stored to User Documents. Inspection of the User Documents folder shows the image file correctly stored. Copying this file to my user-account creates a copy that can be loaded (for example) into the Preview application or else iPhoto. The expected image is loaded by Preview and iPhoto and can be seen to be visually correct.
(ii) On attempting to read the stored file with the standard method
UIImage * image = [ UIImage imageWithContentsOfFile: file ]
method (where file is the full path-name of the stored file) the image returned is nil. nil is also returned on attempting an NSData load via
NSData * data = [ NSData dataWithContentsOfFile: file options:
NSDataReadingMappedIfSafe error: & error ];
In this case the full NSError * error object is reported as follows:
CODE= 260, DOMAIN= NSCocoaErrorDomain,
USERINFO =
{ NSFilePath = "<User Documents>/<filename>.jpeg";
NSUnderlyingError = "Error Domain=NSPOSIXErrorDomain
Code=2 \"The operation couldn't be completed. No such file or directory\"";
}
(iii) Examining the copied file in Finder shows that the "Kind" of the previousl;y written image-file is now "Document" wheras previously it was (as expected) "JPEG Image". This is the ONLY evident problem with the file.
(iv) Replacing the previous written file with an externally created JPEG image file WITH EXACTLY THE SAME NAME results in a successful loading of the file via [ UIImage imageWithContentsOfFile: file ]!
THIS LOOKS, THEREFORE, TO BE A PERMISSIONS PROBLEM RATHER THAN A JPEG-DATA PROBLEM. New with XCode 4.3 installation is the Kind= "Document" replacing the previous (and working) Kind = "JPEG Image". CAN ANYONE PLEASE THROW LIGHT ON THIS MATTER AND IF POSSIBLE ADVISE A SOLUTION? The matter is urgent & frustrating for me as it breaks a PDF design tool under urgent development!
Best Wishes,
Negative Entropy
Can you debug and "po file" from the console? I've not seen a permission problem before, so I suspect the path. Also, we have seen issues with case sensitivity (iOS is case sensitive, whereas your Simulator may not be). Need to see the full path variable contents.

iOS: Core data and disk space

Does anyone know what happens if you try to save to core data, but there is not enough disk space left?
I'm assuming the save operation generates an NSError of some kind? How would you tell it was a disk space error not some other error during disk write?
After a few hours of trying to fill up the disk, I've found that the error you get is:
NSSQLiteErrorDomain = 13;
NSUnderlyingException = "error during SQL execution : database or disk is full";
It is rather difficult to get this error:
iOS devices claim to be full before they really are. I managed to squeeze an extra 206MB onto an iPod that claimed to have 0 bytes free.
As the device fills up, it automatically starts deleting caches and other temporary files.
This seems to be a poor choice by the CoreData developers when implementing their Error handling API. instead of defining a NSCoreDataErrorDomain they're overloading NSCocoaErrorDomain and passing up SQLite error codes defined here.
You can find out the error by querying the NSError instance and parsing the result for the error domain involved. One of these domains probably has the error code you are looking for:
// Predefined domain for errors from most AppKit and Foundation APIs.
FOUNDATION_EXPORT NSString *const NSCocoaErrorDomain;
// Other predefined domains; value of "code" will correspond to preexisting values in these domains.
FOUNDATION_EXPORT NSString *const NSPOSIXErrorDomain;
FOUNDATION_EXPORT NSString *const NSOSStatusErrorDomain;
FOUNDATION_EXPORT NSString *const NSMachErrorDomain;

Other causes for DirectShow "no combination of intermediate filters could be found" errors?

I have a Delphi 6 application that uses the DSPACK DirectShow component library. Currently I am getting the error "no combination of intermediate filters could be found" when I attempt to connect the Capture pin on an audio capture device to the Input pin of another filter. I believe I am setting the media formats correctly. I have an error trap and in that trap I query explicitly both pins for the exact media format they are set to in case there is an incongruity. When I do this, both pins come back with the exact same WAV format:
format tag: 1
number of channels: 1
bits per sample: 16
sample rate: 8000
That matches up to what I set both filters to, yet I am getting an error that (usually as far as I know) indicates a format incompatibility. Has anyone run into this error before and knows what I might be doing wrong or what other kinds of tests/inspections I can do?
It turns out the error was being caused by the media format I was returning from my push source audio filter. I had the wrong sub-type and that was triggering the "no combination of intermediate filters could be found" error from DirectShow since the sub-type I was using in my push source filter was incorrect and not compatible with other filters like the Capture filter I was using in my filter graph. See the "UPDATE" note in my thread on media format's for full details:
Correct Media Type settings for a DirectShow filter that delivers Wav audio data?

Resources