I\'m a professional C programmer and a hobbyist Obj-C programmer (OS X). Recentl

Question

I'm a professional C programmer and a hobbyist Obj-C programmer (OS X). Recently I've been tempted to expand into C++, because of its very rich syntax.

So far coding I haven't dealt much with exceptions. Objective-C has them, but Apple's policy is quite strict:

Important You should reserve the use of exceptions for programming or unexpected runtime errors such as out-of-bounds collection access, attempts to mutate immutable objects, sending an invalid message, and losing the connection to the window server.
C++ seems to prefer using exceptions more often. For example the wikipedia example on RAII throws an exception if a file can't be opened. Objective-C would return nil with an error sent by a out param. Notably, it seems std::ofstream can be set either way.

Here on programmers I've found several answers either proclaiming to use exceptions instead of error codes or to not use exceptions at all. The former seem more prevalent.

I haven't found anyone doing an objective study for C++. It seems to me that since pointers are rare, I'd have to go with internal error flags if I choose to avoid exceptions. Will it be too much bother to handle, or will it perhaps work even better than exceptions? A comparison of both cases would be the best answer.

Edit: Though not completely relevant, I probably should clarify what nil is. Technically it's the same as NULL, but the thing is, it's ok to send a message to nil. So you can do something like

NSError *err = nil;
id obj = [NSFileHandle fileHandleForReadingFromURL:myurl error:&err];

[obj retain];
even if the first call returned nil. And as you never do *obj in Obj-C, there's no risk of a NULL pointer dereference.

Explanation / Answer

Here's the thing: Because of C++'s unique history and flexibility, you can find someone proclaiming virtually any opinion about any feature that you'd like. However, in general, the more that what you're doing looks like C, the worse an idea it is.

One of the reasons that C++ is much looser when it comes to exceptions is that you can't exactly return nil whenever you feel like it. There's no such thing as nil in the vast majority of cases and types.

But here's the simple fact. Exceptions do their work automatically. When you throw an exception, RAII takes over and everything is handled by the compiler. When you use error codes, you have to remember to check them. This inherently makes exceptions significantly safer than error codes- they check themselves, as it were. In addition, they're more expressive. Throw an exception and you can get out a string telling you what the error is, and can even contain specific information, like "Bad parameter X which had value Y instead of Z". Get an error code of 0xDEADBEEF and what, exactly, went wrong? I sure hope the documentation is complete and up-to-date, and even if you get "Bad parameter", it's never going to tell you which parameter, what value it had, and what value it should have had. If you catch by reference, as well, they can be polymorphic. Finally, exceptions can be thrown from places where error codes never can, like constructors. And how about generic algorithms? How is std::for_each going to handle your error code? Pro-tip: It isn't.

Exceptions are vastly superior to error codes in every respect. The real question is in exceptions vs assertions.

Here's the thing. Nobody can know in advance what pre-conditions your program has for operating, what failure conditions are unusual, which can be checked for beforehand, and which are bugs. This generally means that you cannot decide beforehand whether a given failure should be an assertion or an exception without knowing the program logic. In addition, an operation which can continue when one of it's sub-operations fail is the exception, not the rule.

In my opinion, exceptions are there to be caught. Not necessarily immediately, but eventually. An exception is a problem that you expect the program to be able to recover from at some point. But the operation in question can never recover from a problem which warrants an exception.

Assertion failures are always fatal, unrecoverable errors. Memory corruption, that sort of thing.

So when you can't open a file, is it an assertion or exception? Well, in a generic library, then there are plenty of scenarios where the error can be handled, for example, loading a configuration file, you might simply use a pre-built default instead, so I'd say exception.

As a footnote, I'd like to mention there's some "Null Object Pattern" thing going around. This pattern is terrible. In ten years, it will be the next Singleton. The number of cases in which you can produce a suitable null object is miniscule.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.