On Oct 3, 2013, at 4:49 PM, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> 
> Just because it won't kill anyone doesn't mean that it's okay for it to continue after it's in a bad state. It could do other nasty things to the system (including corrupt the files that it's operating on). Once a program's in an invalid state, all bets are off. I fully concur with Walter that it's better to kill the program at that point and restart it whether lives are on the line or not. And if that means that the user sees crashes, oh well. They'll complain and the developer will have to fix them, which is exactly what they need to do, because they wouldn't be getting stuff like segfaults or Errors if their code wasn't broken.

I'm inclined to agree.  However, in this case the user will need some method to remove the broken plugin or the app will be perpetually broken.  It wouldn't surprise me if the original motivation for trying to withstand failures was a bad decision motivated by something like this, and at some point it was erroneously considered a feature.  I'd prefer to be notified that a crash was likely caused by a bad plugin and given the option to restart in "safe" mode, though.

On 10/4/13, Walter Bright <newshound2@digitalmars.com> wrote:
> Continuing program execution after it failed due to programming bugs is just a bad, bad, bad idea, and it needs to die.

Then why did you introduce the Error exception type into the language in the first place? I mean why would you let exceptions propagate up the call stack if the state of the program is seriously compromised? Why not just call the system's exit() function?

If nobody up the call stack could do anything useful, then there's no point in walking up the call stack. And yet we have Error that does exactly that.

What I'm saying is the act of throwing an Error itself is an act of continuing program execution after a serious failure. And here you are arguing against it.

On Friday, October 04, 2013 02:55:36 Andrej Mitrovic wrote:
> On 10/4/13, Walter Bright <newshound2@digitalmars.com> wrote:
> > Continuing program execution after it failed due to programming bugs is just a bad, bad, bad idea, and it needs to die.
> 
> Then why did you introduce the Error exception type into the language in the first place? I mean why would you let exceptions propagate up the call stack if the state of the program is seriously compromised? Why not just call the system's exit() function?
> 
> If nobody up the call stack could do anything useful, then there's no point in walking up the call stack. And yet we have Error that does exactly that.
> 
> What I'm saying is the act of throwing an Error itself is an act of continuing program execution after a serious failure. And here you are arguing against it.

I've actually been wondering about that too. The only case I can think of where catching an Error and continuing _might_ make sense would be with OutOfMemoryError if you caught it right after it was thrown and then did something differently based on the fact that you'd run out of memory. But pretty much all other Errors are outright programming bugs, and all you really need is the stacktrace. Unwinding the stack (even with skipping destructors, finally blocks, etc.) seems extraneous at that point.

- Jonathan M Davis

On 10/3/2013 5:55 PM, Andrej Mitrovic wrote:
> On 10/4/13, Walter Bright <newshound2@digitalmars.com> wrote:
>> Continuing program execution after it failed due to programming bugs is just
>> a bad, bad, bad idea, and it needs to die.
>
> Then why did you introduce the Error exception type into the language
> in the first place? I mean why would you let exceptions propagate up
> the call stack if the state of the program is seriously compromised?
> Why not just call the system's exit() function?
>
> If nobody up the call stack could do anything useful, then there's no
> point in walking up the call stack. And yet we have Error that does
> exactly that.
>
> What I'm saying is the act of throwing an Error itself is an act of
> continuing program execution after a serious failure. And here you are
> arguing against it.


Error exceptions are not necessarily program bugs. They are non-recoverable errors, which is not the same thing.

On 2013-10-04 02:08, H. S. Teoh wrote:

> Reminds me of a GUI app I tried years ago, that suffered from some kind
> of memory corruption bug. Every now and then it would segfault due to
> hitting the corruption... one time, it *didn't* segfault, but continued
> merrily on and corrupted all of my data -- worth many hours of work --
> all without showing any signs of problems, and then out of habit I saved
> the file I was working on, and it barged ahead and wrote garbage all
> over my last good copy of the data. :-(

I have had the same experience. We had to use an application in school that was notorious to crash and corrupt your files. I kept ten different save files, cycled through them when I saved. When it did crash it corrupt not just the file I was working on but five other of my ten save files. Of course, these we're the five latest files and the other were too old. That really sucked.

-- 
/Jacob Carlborg

On 10/3/2013 11:46 PM, Jacob Carlborg wrote:
> On 2013-10-04 02:08, H. S. Teoh wrote:
>
>> Reminds me of a GUI app I tried years ago, that suffered from some kind
>> of memory corruption bug. Every now and then it would segfault due to
>> hitting the corruption... one time, it *didn't* segfault, but continued
>> merrily on and corrupted all of my data -- worth many hours of work --
>> all without showing any signs of problems, and then out of habit I saved
>> the file I was working on, and it barged ahead and wrote garbage all
>> over my last good copy of the data. :-(
>
> I have had the same experience. We had to use an application in school that was
> notorious to crash and corrupt your files. I kept ten different save files,
> cycled through them when I saved. When it did crash it corrupt not just the file
> I was working on but five other of my ten save files. Of course, these we're the
> five latest files and the other were too old. That really sucked.


I think it's pretty clear that the solution to saving a user's work-in-progress is to have the application actually save the work-in-progress at regular intervals, not try to save it after it has crashed.

On 2013-10-04 09:40, Walter Bright wrote:

> I think it's pretty clear that the solution to saving a user's
> work-in-progress is to have the application actually save the
> work-in-progress at regular intervals, not try to save it after it has
> crashed.

Yes, but I don't know why it touched five of my save files. I can understand that it corrupted one, but not five.

-- 
/Jacob Carlborg

On 10/4/2013 1:50 AM, Jacob Carlborg wrote:
> On 2013-10-04 09:40, Walter Bright wrote:
>
>> I think it's pretty clear that the solution to saving a user's
>> work-in-progress is to have the application actually save the
>> work-in-progress at regular intervals, not try to save it after it has
>> crashed.
>
> Yes, but I don't know why it touched five of my save files. I can understand
> that it corrupted one, but not five.

Because its internal logic and code got scrambled, it can exhibit any behavior. That's the point.

On 9/30/13, Adam D. Ruppe <destructionator@gmail.com> wrote:
> Is there anything we can do to automatically clean up if the user hits ctrl+c on Linux?

What's interesting is I just ran into this SEH enum in druntime for
win32 by chance:
CONTROL_C_EXIT

But there's no equivalent for linux. Tough luck. :)

On Oct 5, 2013, at 4:09 PM, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> 
>> On 9/30/13, Adam D. Ruppe <destructionator@gmail.com> wrote:
>> Is there anything we can do to automatically clean up if the user
>> hits ctrl+c on Linux?
> 
> What's interesting is I just ran into this SEH enum in druntime for
> win32 by chance:
> CONTROL_C_EXIT
> 
> But there's no equivalent for linux.

You need to trap SIGINT. But then you're stuck in a signal handler and so can't do much to clean up.