View mode: basic / threaded / horizontal-split · Log in · Help
April 05, 2013
Re: DIP33: A standard exception hierarchy
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
April 05, 2013
Re: DIP33: A standard exception hierarchy
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*.
April 06, 2013
Re: DIP33: A standard exception hierarchy
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.
April 06, 2013
Re: DIP33: A standard exception hierarchy
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.
Next ›   Last »
10 11 12 13 14
Top | Discussion index | About this forum | D home