I get the following error in XCode...
I've added a "Swift Error" breakpoint and left the "Type" box empty. I thought this might show some further info, but it doesn't appear to have any effect.
How can I find out where this error is arising from?
EXC_BAD_INSTRUCTION means that you have an invalid assertion (usually a force-unwrapped nil, though a bad cast could also be the culprit, here). Make sure that tourDto is a populated var, and that it can be cast to whatever toJSONString() returns (I'm not familiar with that method, and it could also be the culprit).
Related
I am trying to debug my Autolayout using the suggestions of this website, to highlight views that are causing constraint issues. However when I try to change the color of the suspect view with the command
expr ((UIView *)0x7f9ea3d43410).backgroundColor = [UIColor redColor]
I get the Error
error: Execution was interrupted, reason: EXC_BAD_ACCESS (code=1, address=0xcd4200020).
The process has been returned to the state before expression evaluation.
I have also gotten the error:
error: Execution was interrupted, reason: Attempted to dereference an invalid ObjC Object or send it an unrecognized selector.
The process has been returned to the state before expression evaluation.
I am not sure why I am getting this error as I have made sure to replace the example hex code with my own, what does this error even mean?
I am coding in swift, the website I reference uses objective-c, that may be my problem. what would the swift code be to do the same thing? I have tried:
expr ((UIView *)0x7f9ea3d43410).backgroundColor = UIColor.redColor
I think the short answer is "that link is from 2015 and the recommended technique uses hidden internal symbols that are no longer supported."
Specifically, the symbol is _autoLayoutTrace. That is a private symbol which apparently has been dropped.
I am using this line of code
let transactions = SKPaymentQueue.default().transactions
This is what Apple amazing docs has to say about transactions.
What is exactly "undefined"? How do I test transactions before proceeding in code?
I have an observed attached to the payment queue.
I can guarantee you that undefined is not nil, because I have tested for nil and Xcode whined with an error
Comparing non-optional value of type '[SKPaymentTransaction]' to 'nil' always returns false
is undefined the new "empty array"? If not, how do I test for that?
Undefined means literally that: the API does not define what the framework will do. Anything is "fair game".
The code might cause a fatal error, return an empty array, or trigger a workflow to send a postcard to you in the mail. It's not defined.
However, no matter what the current behaviour happens to be, you shouldn't depend on it. It might return an empty array today, but crash tomorrow. Because the API explicitly documents the behaviour as undefined, Apple is free to change implementation details, without them counting as "API breaking changes".
While decrypting I get the error : The operation couldnot be performed RNCryptorError 1
I dont understand what I am doing wrong. Here is my block of code
For anyone who might search here: this is a duplicate of RNCryptor#174, and you may want to read there as well.
Please just post code into the question rather than a screenshot. I can't compile a screenshot, and they're very hard to read.
Error 1 is an HMAC error. Either your data is corrupted or your password is incorrect.
Note that NSException never makes sense in Swift. Switch can't catch them. They only make sense in ObjC if you're going to crash the program shortly after. They're not memory-safe in ObjC. You meant to use Swift's throw and ErrorType, which are unrelated to raise or NSException.
My Swift application running in iOS simulator is being stopped in debugger with runtime error EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, sub code=0x0).
According to the WWDC 2014 Session 409 this is typically due to assertion failure.
In the current development Beta version of Xcode 6, the debugger’s stack trace and the above error does not provide enough information to see what the issue is. How do I find out where the problem is?
It appears that the most common source of this error (at the time of this writing: Xcode 6 Beta 1) is that some implicitly unwrapped optional property or variable is nil.
For convenience, most Objective-C API are bridged to Swift with implicitly unwrapped optionals. They are denoted by exclamation mark behind the type declaration: AnyObject[]!
If the debugger stops in your code, double-check that line and look for implicitly unwrapped optionals that could be nil there.
Sometimes the debugger stops with that runtime error deep in Swift system library. This happens for example when you pass a closure to collection methods like filter, map, reduce et al. The runtime error then occurs at the call site of those library functions, but the definition might be in different parts of your code, where you defined the function/closure. Look there for implicitly unwrapped optionals that might be nil at runtime.
To guard agains these kinds of error be aware that even though Swift compiler will not force you to handle the potential nil values returned from Cocoa, you should use optional binding, optional chaining
or optional downcasting wherever the return value from Objective-C land might be nil.
Let’s hope that future versions of Swift compiler will start emitting more helpful diagnostic messages and errors for this common type of problem!
I have found (after many hours) that this error can appear on the wrong line.
For example
As you can see the app is crashing where I am checking for nil, but then 'continuing' through because it prints the statements. It then goes 'backwards' and crashes.
I've come to the conclusion that there is a source-mapping bug in XCode (7) where a nil variable is un-wrapped. In this case, I had a variable (much farther down in my code) that was nil and being unwrapped.
The problem of course is that the compiler didn't flag the actual variable that was nil, it flagged something else entirely.
So if you run into this nasty bug, go through all possible variables that can be nil and check them for unwrapping. You are likely unwrapping a nil, its just not the one the compiler says.
As mentioned in the comment there is compiler optimization. Here is a link to fix the issue (and find the route cause of the crash)
xcode 6.1 how to disable optimization (Swift)
I had the same issue as Palimondo. Fortunately, it was simply a matter of making sure that I had initialized the item ahead of time. In my code, I was calling a function to place images in UIImageViews and passing in an element from an array. I had not yet loaded my array with the UIImageViews, and therefore when the code would run it would say that I was passing in a nonexistent element of the array. Once I made sure to load up my array at the start of the program the error went away.
I am not able to understand the places where an error handling or where an exception handling should be used. I assume this, if it is an existing framework class there are delegate methods which will facilitate the programmer to send an error object reference and handle the error after that. Exception handling is for cases where an operation of a programmer using some framework classes throws an error and i cannot get an fix on the error object's reference.
Is this assumption valid ? or how should i understand them ?
You should use exceptions for errors that would never appear if the programmer would have checked the parameters to the method that throws the exception. E.g. divide by 0 or the well known "out of bounds"-exception you get from NSArrays.
NSErrors are for errors that the programmer could do nothing about. E.g. parsing a plist file. It would be a waste of resources if the program would check if the file is a valid plist before it tries to read its content. For the validity check the program must parse the whole file. And parsing a file to report that it is valid so you can parse it again would be a total waste. So the method returns a NSError (or just nil, which tells you that something went wrong) if the file can't be parsed.
The parsing for validity is the "programmer should have checked the parameters" part. It's not applicable for this type of errors, so you don't throw a exception.
In theory you could replace the out of bounds exception with a return nil. But this would lead to very bad programming.
Apple says:
Important: In many environments, use of exceptions is fairly commonplace. For example, you might throw an exception to signal that a routine could not execute normally—such as when a file is missing or data could not be parsed correctly. Exceptions are resource-intensive in Objective-C. You should not use exceptions for general flow-control, or simply to signify errors. Instead you should use the return value of a method or function to indicate that an error has occurred, and provide information about the problem in an error object.
I think you are absolutely right with your assumption for Errors and for it framework provide a set of methods (UIWebView error handling ), But your assumption for Exception partially right because the exception only occurred if we do something wrong which is not allowed by the framework and can be fixed. (for example accessing a member from an array beyond its limit).
and will result in application crash.