On Friday, April 05, 2013 15:42:00 deadalnix wrote:
> Removing the plug a failure that is way more serious than an array out of bound access. Why do we want to worsen the array thing just because the later may happen ?
> 
> I guess that is the same logic that lead to theses cars we see in movies that explode each time something goes wrong. After all, the car is likely to be broken, so let's just let it explode.
> 
> Back on a more software related example. Let's consider a media player in which such error occurs (such software uses a lot of 3rd party code to support many format, desktop integration, whatever). How to argue that the software must plain crash, and, by the way, the config and playlist are not saved, so you'll restart the soft playing random crap preferably at maximum volume in your headphones (bonus point if it is some porn in a public area), instead of simply displaying a graphical glitch, skip a frame, go to the next item in the playlist, or even quit while saving the playlist/config so it can be restarted and the user can resume its film ?
> 
> Right now, it isn't even possible to try a graceful shutdown when really, the program is unlikely to be in a completely unpredictable state, especially in @safe code.

Part of the point is that if you had an Error, there _is_ no graceful shutdown. It's in an invalid state. Doing _anything_ at that point is risky. Depending on why the Error occurred, you could just as easily completely corrupt playlist files as properly update them. If you have an Error, you basically just crashed. Don't expect that to be any cleaner than if someone just pulled the plug on your computer.

The fact that an Error is thrown rather than the program simply aborting gives you some chance of saving your program in circumstances where you actually know that catching the Error and continuing can work (e.g. in rare circumstances, that might work with OutOfMemoryError), and it gives you the chance tot attempt some truly critical clean-up code if you want to, but again, you can _never_ rely on clean-up happening correctly 100% of the time no matter what the language does, because your program could be forcibly killed by kill -9 or by power loss or whatever. So, if there's anything that you need to do in order to guarantee that your program always has consistent state, don't even rely on Exceptions for that. It won't always work.

Errors should be extremely rare. It's not like you just had bad input. If an Error occurs, something seriously wrong happened in your program. It could be a programming bug that you never caught, or it could be that you have data corruption or that your hardware is actually busted and doing the wrong thing. You can't know what's going wrong, so you can't know how safe it is to attempt clean-up code. Maybe it is, maybe it isn't. It's basically the same as if your computer outrigt crashed. And do you really expect that to go cleanly?

All the programs that I use that have playlists and the like return to a previously valid state when they crash or are killed - either by updating their state as they go along and making sure that they do so in a way that the playlist is valid and/or by restoring to the state that they were in when the program last shutdown correctly. Neither of those require that Errors be handled. Rather, they require making updates after successful operations. It's then pretty much irrelevant if future operations go horribly wrong. When you start the program up again, it'll simply put itself back in the last known good state.

- Jonathan M Davis

On Friday, 5 April 2013 at 13:42:02 UTC, deadalnix wrote:

> Right now, it isn't even possible to try a graceful shutdown when really, the program is unlikely to be in a completely unpredictable state, especially in @safe code.

It is possible. Catch the error.

However, having the language pretend that it can make any logical guarantees to you like it does with exceptions (i.e. finally blocks, chaining etc.) only encourages people not to take Errors as seriously as one should.
Soon people are throwing errors where they should be exceptions and vice versa. Even worse: people will be catching errors everywhere and their code could be happily running for days performing undefined behaviour.

This is a similar situation to shared (although with some important differences). Making it easier to use would be like putting a seatbelt on a motorbike. Sure, it might be safer some of the time. It'll definitely require less care to use. But when the bike slips sideways underneath you going round a bend at 80mph, you need to kick it away as fast as possible.
It'll save you all the times it *doesn't* matter, but it'll kill you that one time when it *does*.

On Friday, 5 April 2013 at 18:38:46 UTC, Jonathan M Davis wrote:
> Part of the point is that if you had an Error, there _is_ no graceful
> shutdown. It's in an invalid state. Doing _anything_ at that point is risky.
> Depending on why the Error occurred, you could just as easily completely
> corrupt playlist files as properly update them. If you have an Error, you
> basically just crashed. Don't expect that to be any cleaner than if someone
> just pulled the plug on your computer.
>

That is once again nonsense. It MAY not be possible to recover, it doesn't mean that not even make it possible to try is the right thing to do.

On Friday, 5 April 2013 at 19:39:14 UTC, John Colvin wrote:
> On Friday, 5 April 2013 at 13:42:02 UTC, deadalnix wrote:
>
>> Right now, it isn't even possible to try a graceful shutdown when really, the program is unlikely to be in a completely unpredictable state, especially in @safe code.
>
> It is possible. Catch the error.
>

No.

At this point, the small issue is already transformed in complete havoc. Mutexes are not released, nothing is cleaned up, etc . . .

> However, having the language pretend that it can make any logical guarantees to you like it does with exceptions (i.e. finally blocks, chaining etc.) only encourages people not to take Errors as seriously as one should.
> Soon people are throwing errors where they should be exceptions and vice versa. Even worse: people will be catching errors everywhere and their code could be happily running for days performing undefined behaviour.
>

Well go all the way down the reasoning : nothing ensure that the stack isn't corrupted and that unwinding is possible.

> This is a similar situation to shared (although with some important differences). Making it easier to use would be like putting a seatbelt on a motorbike. Sure, it might be safer some of the time. It'll definitely require less care to use. But when the bike slips sideways underneath you going round a bend at 80mph, you need to kick it away as fast as possible.
> It'll save you all the times it *doesn't* matter, but it'll kill you that one time when it *does*.

I'm not sure a media player can kill me.