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.
Related
I am new in SwiftUI and I am currently developing my first big application.The program runs successfully in the simulator however the simulator screen is all white and I get the error:
Thread 1: EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
in the AppDelegate(to which I have made no changes)
the app already consists of multiple files , however I can not find any problems in my code however many times I check it. What type of error should I be looking for?
In the context of Swift code,
EXC_BAD_INSTRUCTION
usually means you’ve hit a compiler trap, that is, an undefined instruction inserted into the code by the compiler because of a bug detected at runtime. The most common cause of these are:
failure to unwrap an optional —
This can be a forced unwrap (!) or an implicit unwrap (accessing an implicitly unwrapped optional that’s nil).
array out of bounds
a failed forced cast (as!), either because the value was a nil optional or because the value was of the wrong type
You can debug this issue by creating a exception breakpoint. As the name suggests, this stops the code execution before the execution of the line that throwed this exception.
To Create a exception breakpoint in Xcode, Go to BreakPoint navigator -> Click the + icon at the bottom left corner -> Select Exception Breakpoint.
More about breakpoints check this link
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).
I'm used to working with SQL database, I'm new to Realm and, so far, I'm really impressed by the ease of use of this new mobile database.
But there is something that I really don't undestand: how to handle error throwing?
Take this simple example:
I want to store in a Realm DB some market stocks.
Each stock has a "symbol" as a unique identifier: APPL for Apple Inc, TSLA for Tesla Motors Inc, etc.
I believe it would make sense to declare these symbols as primary keys, since it's not possible to have multiple times the same symbol in the database
When user clicks on a symbol (among a list of symbols), this symbol is saved in db.
In this Raywenderlich tutorial, it is said: "To simplify the code required in this tutorial, you’ll be used try! when calling Realm methods that throw an error. In your own code, you should really be using try and do / catch to catch errors and handle them appropriately."
So according to the following pattern:
do {
try realm.write {
realm.add(symbol)
}
}
catch let error as NSError {
print("Something went wrong: \(error.localizedDescription)")
}
So far it makes sense.
And if a user clicks on a symbol that is already in the database, I get (very logically) an error:
*** Terminating app due to uncaught exception 'RLMException', reason: 'Can't set primary key property 'symbol' to existing value 'APPL'.'
The problem is that this error is not catched during run time: I've got a crash instead.
My question is not about how to avoid such a crash, I understand of course that it's easy to avoid it by doing a simple testing before writing anything in the database :)
My question is how do we do in Realm to catch potential writing errors?
Am I doing something wrong?
do/try/catch in Swift catch Swift Errors, which are an entirely distinct thing from Objective-C exceptions. Realm follows Foundation's pattern for error reporting: API misuse errors throw exceptions which are not intended to be caught (and can't be caught in Swift), and recoverable errors throw Swift errors (or use NSError out parameters in Objective-C).
Adding an object with a duplicate primary key is considered API misuse, so it's a fatal error as the route for "handling" it is to fix the bug in your code. An example of a recoverable error which would produce a Swift error that would be caught by catch is running out of disk space while trying to save the new data.
There are two distinct types of error: programmer error, and expected errors. Realm handles these two types of errors differently.
Programmer error covers cases such as accessing objects from incorrect threads, out-of-bounds collection access, attempting to insert an object with a duplicate primary key, and so forth. Realm responds to these programmer errors by throwing an Objective-C exception. These exceptions are not intended to be caught and handled as they're indicative of a bug in a Realm user's code.
Expected errors cover things like files not existing, permission errors, failures to write to disk. These are things that can happen even with correctly-written code due to factors outside of the programs control. These are exposed as NSErrors and can be caught from Swift using do / try / catch. Note that Realm's Objective-C API has some convenience methods that don't expose the NSError. In these cases an expected error will throw an exception as there's no other avenue for Realm to communicate the failure. Rather than attempting to catch and handle exceptions raised by these convenience methods, you should use the variant of the API that returns an NSError instead.
Hi, the error line said "to existing value", don't you try to write more than one time the same primary key with 'APPL' ?
you need to update it, not override.
if you try to "add" again the same value, it's gonna stop you.
(sorry for bad english x) )
I am getting the following error at the mentioned line of code
Even though the debugger shows that bg has been assigned a value, that it fetches from .sks file. (GameScene.sks file contains an object named as bg)
Any help would be highly appreciated.
-> -> EDIT
Whilst no thanks to the community here thats full of people who'd just try to be uncanningly witty and gods of humor, i managed to figure it out myself. So for a future reference if someone else falls in the same situation, i am sharing the code that was the reason for the problematic error.
At this point in time the debugger will show a value for bg that was previously there on the stack (garbage in the memory).
It will never write something to bg because the program crashes while evaluating the value for the variable so you are just seeing garbage.
The error you can see clearly means there is no node named bg.
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.