Post marked as solved
Click to stop watching this thread.
You have stopped watching this post. Click to start watching again.
contentPostList.repliessolved.tooltip
Replied In
C++ exceptions on iOS
John, I don't know what you are talking about. My code base uses C++ exceptions and they work as intended. I don't know what you mean by Apple's implementation of exception handling being "improper". They throw and are caught exactly as the language specifies (at least with C++, I've never really used ObjC exceptions). Of course the response to an uncaught exception is to crash the app. What else would it be? Also I don't know why you think refactoring an entire code base, especially one that is multi-platform, to not use exceptions is any more feasible than adding try-catch blocks. Errors indicate an inability to proceed forward unless the code expects and can handle the error case, so making an error something that could quietly pass is setting myself up for crashes that are far harder to debug than what I have now. If I used a logger that called abort, the equivalent issue would be forgetting to call the logger on an unhandled error, and then the app keeps running until it crashes later for non-obvious reasons. I very much want the app to stop executing if an exception occurs and no try-catch was in place to indicate it has been properly handled. In fact since I use such strict type safety, it wouldn't be possible to code to this. I throw exceptions in functions that can't return a validly constructed instance of whatever type they return. Your suggestion of logging is what I already do but it's added to the log of a thrown exception (see below).David, a partial workaround is to define your own Exception class and use it in as many places as possible as a base for all your exceptions. Have this class capture the stack trace on construction and add it to the "what". This gets around the problem for debug builds, but for me it doesn't help with release builds because apparently the symbols aren't matching up (the stack trace it produces is obviously invalid). I may have something configured incorrectly in my project but I haven't dug around enough to find out for sure.eskimo I don't know if you have any insight on that. Apparently [NSThread callStackSymbols] isn't reliable on release builds with all the optimizations turned on? Definitely on App Store builds and also on ad-hoc release-mode builds IIRC. What's odd is that it prints out actual symbols from the code, just not the right ones. Maybe I need to capture the raw stack frames and try to desymbolicate them afterword?