Xojo error handling code#
If it finds an exception handler, it transfers control to that handler which then runs the code in the catch block.įor more information about how C++ exceptions work, see C++ ABI for Itanium: Exception Handling.
When some function throws an exception, it walks up the stack, looking up each function's information and using that to unwind the stack to the next function, until it either finds an exception handler or runs off the end.
Xojo error handling how to#
How can this possibly work? In addition to generating the no-exceptions code, the compiler also generates a table with information about how (and whether) the code handles exceptions and how to safely unwind the stack to exit out of the function in the event that an exception is thrown. Which is to say, it passes in parameters and retrieves return values and gives no thought to the possibility of exceptions.
Xojo error handling full#
Objective-C exceptions (which do exist, although pretty much nobody uses them) use C++'s exceptions mechanism on the modern runtime.Ī full exploration of how C++ exceptions work could fill a book, so we'll have to settle for a brief description.Ĭ++ code that calls throwing functions (which is the default for C++ functions) produces assembly exactly as if it called non-throwing functions. How does its implementation compare? There are a lot of languages out there with exceptions, and many of them do things differently, but the natural comparison is C++. Swift is careful never to use the word "exception" when discussing its error handling system, but it looks a lot like exceptions in other languages. The generated code looks similar to Objective-C code using an NSError ** parameter, and in fact Swift 3's version of it is identical. The caller checks that place for an error, and jumps to the error handling code if so. The throws function returns the thrown error to the caller in a special place. Internally, it looks a lot like returning a Result type, or otherwise returning some sort of error code. The technique on ARM64 is almost the same, with the x21 register serving as the error pointer. It makes the call, then checks if r12 contains anything. Here's what the relevant assembly code in Thrower looks like:Ĭall r14 mov r15, rax test r12, r12 je loc_100002cec The basic idea is the same, but instead of a normal extra parameter, a special register is reserved for the error return. On return, it checks to see if that space now contains an error. The caller allocates some stack space and passes its address in that parameter. Throwing an error consists of writing the error object to the pointer passed in that parameter. The compiler inserts an extra, hidden parameter which is essentially Error *, or NSError **.
Swift 3 works by essentially automating Objective-C's NSError convention. I'll briefly discuss Swift 3, then look a bit deeper at Swift 4, since that's up and coming. It turns out that Swift 3 and Swift 4 do it differently. Of course, now that Swift is open source, I could just go look at the compiler code and see what it does.
0 kommentar(er)
