Mac Apps That Use Garbage Collection Must Move to ARC

[Manu via Digitalmars-d]

On 25 February 2015 at 09:02, ponce via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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.

This is precisely my complaint though. In a production environment
where there are 10's, 100's of people working concurrently, it is
absolutely unworkable that code can be crashing for random reasons
that I don't care about all the time.
I've experienced before these noisy crashes relating to things that I
don't care about at all. It just interrupts my work, and also whoever
else it is that I have to involve to address the problem before I can
continue.

That is a real cost in time and money. I find that situation to be
absolutely unacceptable. I'll take the possibility that an ignored
error code may not result in a hard-crash every time.


> 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.

Right, but as above, this is an expense quantifiable in time and
dollars that I just can't find within me to balance by this reasoning.
I also prefer my crashes to occur at the point of failure. Exceptions
tend to hide the problem in my experience.
I find it so ridiculously hard to debug exception laden code. I have
no idea how you're meant to do it, it's really hard to find the source
of the problem!

Only way I know is to use break-on-throw, which never works in
exception laden code since exception-happy code typically throw for
common error cases which happen all the time too.


> 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

This only fails if runtime state is already broken. Problem is
elsewhere. Hard crash is preferred right here.

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

Opening files is a very infrequent operation, and one of the poster
child examples of where you would always check the error return. I'm
not even slightly upset by checking the return value from fopen.


> 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.

Not necessarily true. You often want to report what went wrong, not
just that "it didn't work".


> 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.

I don't see exceptions are any different in this way. I see internal
exceptions bleed to much higher levels where they've totally lost
context all the time.


> 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.

I'm not sure quite what you're saying here, but I agree with Walter.
In case of hard logic error, the sane thing to do is crash (ie,
assert), not throw...
I want my crash at the point of failure, not somewhere else.


> 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.

Performance inhibition is a factor in considering that I've never used
exceptions, but it's certainly not the decisive reason.