I have a C++ library for Network communication that I need to port for Mac, previously this library was used on Windows C++ app.
The flow of the C++ Network Lib is based on Exceptions in case of errors, instead of returning error code or last error..
Now since on Mac we use Objective-C/C++ for apps. I need to have UI in Objective-C/C++ but the lib used for the core network functionality is the same C++ lib.
So my question is will the objective C be able to handle exceptions thrown by C++ calls ? if so , how ? if not how do I resolve it ? Or do we write a wrapper around C++ Lib calls and consume exceptions and return error codes ?
Please advise, how to solve it..
The exception handling mechanisms available to Objective-C programs are effective ways of dealing with exceptional conditions. They decouple the detection and handling of these conditions and automate the propagation of the exception from the point of detection to the point of handling.
Objective-C is the primary programming language you use when writing software for OS X and iOS. It's a superset of the C programming language and provides object-oriented capabilities and a dynamic runtime.
An object that represents a special condition that interrupts the normal flow of program execution.
A string containing the error domain. The user info dictionary.
Provided you're using iOS or the 64-bit runtime on OS X, things pretty much just work. You can write a C++ style try/catch and it will work as expected, as will @try/@catch. Note that you'll still have the two distinct styles, for Objective-C and C++ exceptions; the only unification is the special case where a catch(...)
or @catch(...)
catches all exceptions, Objective-C or C++. That's marginally useful for centralising your clean-up code, but about all you can then do with the exception itself is @throw it blindly again.
But in any case, exceptions shouldn't be used for flow control in Objective-C (or Objective-C++) programs. You should indeed endeavour to trap the C++ exceptions as they exit the library in question and convert them to a more appropriate mechanism, such as NSError. In particular, avoid letting any of them raise through any Apple or 3rd party frameworks - most such frameworks are not exception safe for Objective-C exceptions, let alone C++ ones, and the consequences are thus undefined (mostly revolving around memory leaks, though many other failures are possible).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With