Mac Apps That Use Garbage Collection Must Move to ARC

[ponce via Digitalmars-d]

On Monday, 23 February 2015 at 09:51:07 UTC, Manu wrote:
> This is going to sound really stupid... but do people actually 
> use
> exceptions regularly?
> I've never used one. When I encounter code that does, I just 
> find it
> really annoying to debug. I've never 'gotten' exceptions. I'm 
> not sure
> why error codes are insufficient, other than the obvious fact 
> that
> they hog the one sacred return value.


I used to feel like that with exceptions. It's only after a 
position involving lots of legacy code that they revealed their 
value.

One (big) problem about error code is that they do get ignored, 
much too often. It's like manual memory management, everyone 
think they can do it without errors, but mostly everyone fail at 
it (me too, and you too).

Exceptions makes a program crash noisily so errors can't be 
ignored.
More importantly, ignoring an error code is invisible, while 
ignoring exceptions require explicit discarding and some thought.
Simply put, correctly handling error code is more code and more 
ugly.
Ignoring exception is no less code than ignoring error codes, but 
at least it will crash.


Secondly, one real advantage is pure readability improvement. The 
normal path looks clean and isn't cluttered with error code 
check. Almost everything can fail!

writeln("Hello");  // can fail
auto f = File("config.txt"); // can fail

What matter in composite operations is whether all of them 
succeeded or not.
Example: if the sequence of operations A-B-C failed while doing 
B, you are interested by the fact A-B-C has failed but not really 
that B failed specifically. So you would have to translate error 
codes from one formalism to another. What happens next is that 
error codes become conflated in the same namespace and reused in 
other unrelated places. Hence, error codes from library leak into 
code that should be isolated from it.


Lastly, exceptions have a hierarchy and allow to distinguish 
between bugs and input errors by convention.
Eg: Alan just wrote a function in a library that return an error 
code if it fails. The user program by Betty pass it a null 
pointer. This is a logic error as Alan disallowed it by contract. 
As Walter repeatedly said us, logic errors/bugs are not input 
errors and the only sane way to handle them is to crash.
But since this function error interface is an error code, Alan 
return something like ERR_POINTER_IS_NULL_CONTRACT_VIOLATED since 
well, no other choice. Now the logic error code gets conflated 
with error codes corresponding to input errors (ERR_DISK_FAILED), 
and both will be handled similarly by Betty for sure, and the 
earth begin to crackle.


Unfortunately exceptions requires exception safety, they may 
block some optimizations, and they may hamper debugging. That is 
usually a social blocker for more exception adoption in C++ 
circles, but once a group really get it, like RAII, you won't be 
able to take it away from them.