Mac Apps That Use Garbage Collection Must Move to ARC

[ponce via Digitalmars-d]

On Wednesday, 25 February 2015 at 16:39:38 UTC, Manu wrote:
> 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.

I see what the problem can be. My feeling is that it is in part a 
workplace/codebase problem. Bugs that prevent other people from 
working aren't usually high on the roadmap. This also happen with 
assertions, and we have to disable them to do work then ; though 
assertions create no debate.

If the alternative is ignoring error codes, I'm not sure it's 
better. Anything could happen and then the database must be 
cleaned up.

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

True eg. you can ignore every OpenGL error it's kind of hardened.

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

To be fair, this cost has to be balanced with the cost of not 
finding a defect before sending it to the customer.


> I also prefer my crashes to occur at the point of failure. 
> Exceptions
> tend to hide the problem in my experience.

I would just put a breakpoint on the offending throw. THen it's 
no different.

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

I've seen this and this is true with things that need to retry 
something periodically with a giant try/catch.
try/catch at the wrong levels to "recover" too much things can 
also make it harder. Some (most?) things should really fail hard 
rather than resist errors.

I think gamedev is more of an exception since "continue anyway" 
might be a successful strategy in some capacity. Games are 
supposed to be "finished" at release which is something customers 
thankfully don't ask of most software.


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

What I do is break-on-uncatched. Break-on-throw is moreoften than 
not hopelessly noisy like you said.

But I only deal with mostly reproducible bugs.

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

But how happy are you to bubble up the error condition up to call 
stack?

I'm of mixed opinion on that, seeing error code _feels_ nice and 
we can say to ourselves "I'm treating the error carefully". Much 
like we can say to ourselves "I'm carefully managing memory" when 
we manage memory manually. Somehow I like pedestrian work that 
really feels like work.

But that doesn't mean we do it efficiently or even in the right 
way, just that we _think_ it's done right.


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

Fortunately exceptions allows to bring up any information about 
what went wrong.

We often see on the Internet that "errors are best dealed with 
where they happen".

I could not disagree more.
Where "fopen" fails, I have no context to know I'm here because I 
was trying to save the game.

Error codes force to bubble up the error to be able to say 
"saving the game has failed", and then since you have used error 
codes without error strings you cannot even say "saving the game 
has failed because fopen has failed to open <filename>".

Now instead of just bubbling up error codes I must bubble up 
error messages too (I've done it). Great!

Errors-should-be-dealed-with-where-they-happen is a complete 
fallacy.

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

In my experience this is often due to sub-systems saving the ass 
of others by ignoring errors in the first place instead of either 
crashing of rebooting the faulty sub-system.


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

assert throw Error for this purpose.

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

And it's a valid concern. Some program parts also seldom need 
exceptions since mostly dealing with memory and few I/O.