Here are two tutorials that Xcode develops to handle exceptions, and suggests a read
The outline is as follows:
Basically you can run into two kinds of crashes: SIGABRT (also called EXC_CRASH ), and EXC_BAD_ACCESS (may also be called SIGBUS or SIGSEGV ).
SIGABRTIs the program is abnormal, easy to locate, EXC_BAD_ACCESS usually directly break the breakpoint in the main, there is a certain skill to find the reason (such as enabling Zombie Objects).
This article describes how to read the error log of the console, describes the exception breakpoint (Exception breakpoint), Lldb (GDB), Zombie object (Zombie Objects), and so on.
Even if you do not have the patience to read the full text, there is a brief summary:
- If the program crashes in MAIN.M, you can consider setting an exception breakpoint
- If you still do not get useful information, you can type the command in lldb
po $eax (extension:, po [$eax class] po [$eax name] , po [$eax reason] ), equal topo [$eax description]
- If you get
EXC_BAD_ACCESS an error, you can enable the Zombie Objects test again to check whether the object that was disposed of has been referenced
- In many cases, exceptions are caused by missing or faulty code that is connected to the designer (story or Xib), and these exceptions are usually not found at compile time and are not easily checked by the code.
- Try to put warnings as errors, and in many cases errors come from the compile-time "warning". If you don't understand how the warning is going to happen, try to study it as clearly as possible.
- Simulator environment is different from real machine, try to connect different real machine Debug
iOS Development Exception Handling tutorial