iOS runtime error handling, any good code options?

[1458279]

I haven't dug into the error handling part of app dev yet, and it looks like what I want to do is not covered in the books I'm using now.

I used to write a universal error handling code set that would catch all catchable errors and records information before the program would crash.

This was with a error handler that was built into the API. In VB/C++/C# apps you would do this with a try... catch... throw and you could then send all the info you needed to your custom error handler function.

So far, I haven't seen anything like this in ObjC. In fact all the code I'm doing now from books has nothing for error handling, like the try..catch.

Is there any book/blog/sample code that goes into depth about writing error handling code on ObjC?

I'm not talking about running / debugging, I'm talking about runtime errors that are caught before the stack trace system dump gets it.

I really hope this doesn't involve putting C++ code around each and every ObjC routine.

Example: I have a line of code that crashes, it doesn't get run until certain conditions. Those conditions are met at runtime, I catch the error, do something to save the app from crashing if I can, then return to program or allow to continue crashing.

 

[robbieduncan]

Depends on how it "crashes". Objective-C has try ... catch blocks but you can only catch thrown exceptions: if you get a memory access error it'll just crash without the catch as this is not an exception.

 

[1458279]

Thanks for the quick reply... so exceptions only. That makes sense as it's called 'exception' handling...

 

[robbieduncan]

Thanks for the quick reply... so exceptions only. That makes sense as it's called 'exception' handling...

I don't see how it can be any other way. C++ is the same: if you try and access memory you don't own the OS will prevent you and kill your process without the chance for your code to catch the failure.

 

[chown33]

So far, I haven't seen anything like this in ObjC. In fact all the code I'm doing now from books has nothing for error handling, like the try..catch.

Is there any book/blog/sample code that goes into depth about writing error handling code on ObjC?

Objective-C Programming Language : Exception Handling.
Exception Programming Topics.
Error Handling Programming Guide.

For sample code, refer to the relevant class reference doc (e.g. for NSException), and look for the words "sample code" on the page.

 

[1458279]

I don't see how it can be any other way. C++ is the same: if you try and access memory you don't own the OS will prevent you and kill your process without the chance for your code to catch the failure.

Ok, that makes sense.
Found a link that should give some insight:
http://www.cocoadev.com/index.pl?ExceptionHandling
Thanks again!

 

[North Bronson]

I'm not talking about running / debugging, I'm talking about runtime errors that are caught before the stack trace system dump gets it.

As far as my experience goes, throwing exceptions is more for programmer-error. If you have run-time errors, the Cocoa way of doing things is usually to try to fail gracefully and report Error objects.

Objective-C and Cocoa are supposed to use exceptions far less frequently than other languages or platforms. Try studying the way that Cocoa objects react to run-time errors and you can find out a little more about the way things are done differently than what you might be experienced with.

 

[PhoneyDeveloper]

I don't think that you'll make this work out. It makes more sense to fix bugs that cause runtime errors than to try to catch them. The nature of iOS is that there are tons of callbacks. Installing try catch blocks in every one of them will make you crazy.

Learn to use the debugger.

 

[1458279]

I don't think that you'll make this work out. It makes more sense to fix bugs that cause runtime errors than to try to catch them. The nature of iOS is that there are tons of callbacks. Installing try catch blocks in every one of them will make you crazy.

Learn to use the debugger.

This is actually separate from the debugger. Kinda hard to explain, but we used to have these as standard equipment. If someone got a problem, we'd pretty much be able to know exactly what they were doing when it happened.
This avoided asking the user 'what where you doing when it crashed?' We would know the settings, call stack, var values etc...

I had one program crash, it was tested over and over again. Everyone that used it had no problem, except one workstation connected to the server.

The admin didn't give that workstation permission to be on that area of the network, so it crashed. This happened after the network was 'upgraded' or changed somehow. The program know exactly why it had crashed and reported it back to the developers, they know exactly how to fix it in short order, and it was fixed.

I've always thought of these kinda things as good cheap insurance, and can help keep a small problem from becoming a bigger problem.

 

[dejo]

Try as hard as you can to prevent runtime errors. But since they're inevitable, crash reports are your friend. Consider incorporating something like QuincyKit, which allows users to submit crash reports to you, should they encounter a crash.