So I am trying to troubleshoot why adding an item to my dictionary causes an exception.
It turns out that I used a NSDictionary instead of NSMutableDictionary.
However the exception I saw... setobject format exception was no help at all.
Where do you look in xCode to get detailed exception information? Or is this all that is given?
It's unfortunate that the emitted stacktrace contains the memory address of the method calls on the stack rather than their names.
I recommend using the debugger and setting a breakpoint at objc_exception_throw. The debugger can tell exactly where the exception was made and what the arguments were.
markjnet provides a nice writeup on exception debugging here.
Related
There is a note in the Swift Docs that states the following:
Error handling in Swift resembles exception handling in other languages, with the use of the try, catch and throw keywords. Unlike exception handling in many languages—including Objective-C—error handling in Swift does not involve unwinding the call stack, a process that can be computationally expensive. As such, the performance characteristics of a throw statement are comparable to those of a return statement.
What does unwinding the call stack mean in Swift and Obj-c? Related question here but it is C++ specific. I know what the call stack is, but would like a more detailed explanation of unwinding.
If Swift doesn't unwind the call stack, what does it do instead?
Why can this be computationally expensive?
Summed up: I'd like to get a better understanding of how exceptions work and the execution flow in Swift.
Unwinding the stack basically means that when an exception is thrown, the method is immediately interrupted, the caller of the method is immediately interrupted and so on until an exception handler (try-catch-finally) is found or until we reach the top of the stack, when the exception usually ends in interrupting the current thread.
That works pretty well in languages with a garbage collector but in general it can lead to memory leaks in languages with manual memory management. Also, since methods are interrupted in unexpected places, an exception often leads to undefined/unrecoverable program states.
That's why exception in all languages should be used sparingly and only to handle exceptional situations, not to handle normal program flow.
Obj-C exceptions weren't very good, with all the problems mentioned above (see NSException, #try-#catch-#finally), that's why nobody is using them. Instead, Obj-C came with error parameters (you pass a reference to a NSError variable and if the method fails, the error gets assigned into that variable). See Error Handling in Objective-C
Swift just came with another syntax for NSError. It's not a real exception handling (errors don't interrupt program execution). See Error Handling in Swift
Technically, every function/method that can throw an error in Swift only has an additional hidden parameter that is used to pass the error back to caller context.
If you want more information, just compare code in Swift 1.x and 2.x (1.x didn't have special grammar for error handling yet).
In Xcode, you can go to the Breakpoints tab, then add a breakpoint for "All Exceptions".
I find this very helpful, but is it possible for this to break the program only when the exception is not handled by a #try {} #catch {} in my code? Those are the only ones that interest me.
It would be even nicer if I could select specific files where I'm interested in using this breakpoint system, although I'm guessing that's a bit too much to ask.
The best I've found is breaking on abort; it will print the exception and backtrace in the log before breaking. You may also have luck setting your own unhandled exception handler and breaking on that.
If you really want to use All Exceptions the way you described, please file a bug with apple:
http://bugreport.apple.com
I recently started learning Objective-C, and I am working on an iOS app as an exercise, anyway, I want to handle overflow by throwing exception (I come from a Java background), I searched the reference there is only NSException, but then I read in the section that say topics about exception handling, and they said to use NSError, I read the reference but they had the same protocol and methods, so what's the difference between them? And which is better?
Also, I want to create my own exception or error class, are there any methods or fields that I should include? (Like when implementing the Exception interface in Java).
Thanks
NSError is designed for non-fatal, recoverable errors. The problems that are designed to be captured by an NSError are often user errors (or are errors that can be presented to the user), can often be recovered from (hence -presentError: and NSErrorRecoveryAttempting), and are usually expected or predictable errors (like trying to open a file that you don't have access to, or trying to convert between incompatible string encodings).
NSException is designed for potentially fatal, programmer errors. These errors are designed to signify potential flaws in your application where you have not correctly checked the pre-conditions for performing some operations (like trying to access an array index that is beyond its bounds, or attempts to mutate an immutable object). The introduction to the Exception Programming Guide explains this a little bit.
Breaking on Objective-C exceptions is really useful and easily the best way to debug issues with NSArray and the like. However, exceptions are also a great thing to use while actually programming.
Xcode offers two choices for breaking on Obj-C exceptions:
Break whenever an exception is thrown
Break whenever an exception is caught
Breaking on catch seems to be basically useless, since the point of #throw is a lot more important. However, if I'm handling an exception fine, I don't want my program to stop.
So, the ideal situation would be: break on all exceptions that are not caught by my code, but show a stack trace for when the exception was thrown.
Another decent solution would be some sort of debugging whitelist for exceptions that should not be broken on.
Is there any way to filter exception breakpoints?
I'm getting some really strange errors in XCode. Whenever I run my program, I get:
malloc: test_node_integrity: FreeListNode 0x1052af0 { _prev =
0xffffffff, _next = 0xffffffff, _size = 0 } failed integrity check.
I've searched all over Google, but haven't found anyone else with this error message. The stack trace has methods that aren't in my program - it's some other thread that XCode is running. Is there anyway I could get more information on this? I've already tried uninstalling/reinstalling XCode (10.5.8, XCode 3.1).
I am using Garbage Collection, so I'm wondering if there is an error there. I used to be getting a different error, "missing cpu_capibilites.h," which would point to a string formatting method. The error changed into one with the debugger not being able to roll back the state, and now I have this error.
If there's any other error information that I should have posted, let me know.
What's happening is that something in your program or a framework it uses is writing into unused memory (the Garbage Collection heap) and destroying internal data structures in the unused memory. The next time something asks AutoZone (the GC memory allocator) to allocate memory, it tries to read the structures in unallocated memory, finds them to be invalid, and throws the above message.
You can read the source that's doing this at http://www.opensource.apple.com/source/autozone/autozone-77.1/AutoAdmin.cpp?f=text
So you need to look for memory smashers.
If this is related to NSOpenPanel being used in conjunction with GC, I think it may be a known problem. See this thread at Cocoabuilder that seems to relate.
The error something thrown by RegexKitLite when I passed it a problematic string. The error message indicated a system-wide error, which is what confused me for so long.