How to intercept EXC_BAD_INSTRUCTION when unwrapping Nil
<p>I am building some rudimentary crash logging system based on <a href="http://chaosinmotion.com/blog/?p=423" rel="noreferrer">this blog post</a> (<em><strong>Yes</strong></em>, I am aware of PLCRashReporter, and <em><strong>No</strong></em>, I can't use it and need to roll my own, however limited. Thank you).</p>

<p>My code registers both an <em>exception</em> handler (with <code>NSSetUncaughtExceptionHandler()</code>) and a <em>signal</em> handler for most signals:</p>

<pre><code>SIGQUIT
SIGILL
SIGTRAP
SIGABRT
SIGEMT
SIGFPE
SIGBUS
SIGSEGV
SIGSYS
SIGPIPE
SIGALRM
SIGXCPU
SIGXFSZ
</code></pre>

<p>It seems to work fine with basic Objective-C stuff such  as "unrecognized selector sent to instance...", etc.</p>

<hr>

<p>Next, I tried it with the following <strong>Swift</strong> code:</p>

<pre><code>var empty:String! = nil

let index = empty.startIndex // &lt; KA-BOOM!
</code></pre>

<p>...but the thrown exception <code>EXC_BAD_INSTRUCTION</code> is not caught (my handler is not called), and instead I get the familiar:</p>

<blockquote>
  <p>fatal error: unexpectedly found nil while unwrapping an Optional value</p>
</blockquote>

<p>...in the Xcode console.</p>

<p><strong>What am I missing?</strong></p>

<p><a href="https://stackoverflow.com/a/38459885/433373">This answer</a> says that this kind of runtime error can be handled with <code>SIGTRAP</code>; however I am already handling that signal and it doesn't seem to work.</p>

<hr>

<p><strong>ADDENDUM:</strong> It seems there is no centralized exception handling system in place  for Swift runtime errors (out of bounds, nil unwrap, etc.); see <a href="https://stackoverflow.com/a/38738365/433373">this post</a>. However, Xcode is still able to crash with <code>EXC_BAD_INSTRUCTION</code>, so my question stands: How is this possible, and why can't my signal handlers  handle this?</p>

<hr>

<p><strong>ADDENDUM 2:</strong> Just to be safe, I tried registering my signal handler for <strong>all</strong> 20+ signals defined in signal.h (not just the ones listed above); still, no change.</p>

<hr>

<p><strong>ADDENDUM 3:</strong> Apple's official document <a href="https://developer.apple.com/library/content/technotes/tn2151/_index.html" rel="noreferrer">Understanding and Analyzing Application Crash Reports</a> contains this snippet: </p>

<blockquote>
  <h3>Trace Trap [EXC_BREAKPOINT // SIGTRAP]</h3>
  
  <p>Similar to an Abnormal Exit, this exception is intended to give an
  attached debugger the chance to interrupt the process at a specific
  point in its execution. You can trigger this exception from your own
  code using the __builtin_trap() function. If no debugger is attached,
  the process is terminated and a crash report is generated.</p>
  
  <p>Lower-level libraries (e.g, libdispatch) will trap the process upon
  encountering a fatal error. Additional information about the error can
  be found in the Additional Diagnostic Information section of the crash
  report, or in the device's console.</p>
  
  <p><strong>Swift code will terminate with this exception type if an unexpected
  condition is encountered at runtime such as:</strong></p>
  
  <ul>
  <li><strong>a non-optional type with a nil value</strong> </li>
  <li><strong>a failed forced type conversion</strong></li>
  </ul>
  
  <p>Look at the Backtraces to determine where the unexpected condition was
  encountered. Additional information may have also been logged to the
  device's console. You should modify the code at the crashing location
  to gracefully handle the runtime failure. For example, use Optional
  Binding instead of force unwrapping an optional.</p>
</blockquote>

<p><em>(emphasis mine)</em></p>

<p>Still: <strong>Why Can't I Handle This With My <code>SIGTRAP</code> Signal Handler?</strong></p>