On Friday, 1 June 2012 at 12:03:15 UTC, deadalnix wrote:
> Le 01/06/2012 12:29, Walter Bright a écrit :
>> On 6/1/2012 1:15 AM, Jens Mueller wrote:
>>> Since the current implementation does not follow the specification
>>> regarding scope and finally block being executed in case of Error will
>>> try ... catch (...Error) keep working?
>>
>> No. The reason for this is the implementation was not updated after the
>> split between Error and Exception happened. It was overlooked.
>>
>>> I have code that uses
>>> assertThrows!AssertError to test some in contracts. Will this code
>>> break?
>>
>> I don't know exactly what your code is, but if you're relying on scope
>> to unwind in the presence of Errors, that will break.
>>
>
> If you have an error, it is already broken in some way.
>
> But this is unreasonable to think that the whole program is broken, except in very specific cases (stack corruption for instance) but in such a case, you can't throw an error anyway.

I agree. It should be possible to have an plugin system where not every null pointer dereference in a plugin screws up the hole program. Without using different processes for the plugin.

90% of null pointer dereferences are simple bugs not memory corruption.

On Fri, 01 Jun 2012 04:48:27 -0400, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> I don't agree that OutOfMemory is critical:
> 	--> make it an exception ?

No.  What we need is a non-throwing version of malloc that returns NULL.  (throwing version can wrap this).  If you want to throw an exception, then throw it there (or use enforce).

Then you call that when you are using it in a recoverable way.

OutOfMemory is critical if you did not write code to handle it.  It's impossible for the compiler to know this, since it has no idea if the error will be caught.  A vast majority of code does *not* recover from out of memory, so the default should be, throw an error.

-Steve

On Friday, 1 June 2012 at 01:16:28 UTC, Walter Bright wrote:

> [When I worked on flight critical airplane systems, the only acceptable response for a self-detected fault was to IMMEDIATELY stop the system, physically DISENGAGE it from the flight controls, and inform the pilot.]

Plane/computer:

ERROR ERROR, I just wanted to inform you that I've detected an error with the landing gear. I will now disengage the landing gear from the plane, I hope you do not need to land.

:)

--
/Jacob Carlborg

On 6/1/12, Tobias Pankrath <tobias@pankrath.net> wrote:
> I agree. It should be possible to have an plugin system where not every null pointer dereference in a plugin screws up the hole program. Without using different processes for the plugin.

It should also be possible to correctly release hardware handles regardless of what happened to the app itself. I hate it when apps lock up and can't be killed (e.g. ones using ASIO hardware).

"deadalnix" <deadalnix@gmail.com> wrote:
> Le 31/05/2012 04:10, Walter Bright a écrit :
>> The correct response to a server app crashing is to restart it, not
>> attempt to keep a program in an invalid state running.
>
> Should I mention to restart it AFTER A GRACEFUL SHUTDOWN ?

No. Abort with crash dump is good way to do controlled shutdown. If there is need for a cleanup, it is better to do it in the upcoming startup where the program state is valid. 

On 6/1/2012 1:48 AM, Dmitry Olshansky wrote:
> Or better - save game and then crash gracefully.

That can result in saving a corrupted game state, which then will not load, or worse, load and then cause another crash.

I would suggest instead implementing an auto-save feature which automatically saves the game state at regular intervals.

On 6/1/2012 6:25 AM, Jacob Carlborg wrote:
> On Friday, 1 June 2012 at 01:16:28 UTC, Walter Bright wrote:
>
>> [When I worked on flight critical airplane systems, the only acceptable
>> response for a self-detected fault was to IMMEDIATELY stop the system,
>> physically DISENGAGE it from the flight controls, and inform the pilot.]
>
> Plane/computer:
>
> ERROR ERROR, I just wanted to inform you that I've detected an error with the
> landing gear. I will now disengage the landing gear from the plane, I hope you
> do not need to land.
>
> :)

I know you're joking, but the people who design these things have a lot of experience with things that fail on aircraft, why they fail, and how to design a system to survive failure.

And the record of airline safety speaks for itself - it is astonishingly, unbelievably, good.

(I don't know the landing gear system in detail, but I do know it has multiple *independent* subsystems to get it down and locked.)

On 6/1/2012 5:29 AM, Steven Schveighoffer wrote:
> No. What we need is a non-throwing version of malloc that returns NULL.

We have it. It's called "malloc"!

:-)

On Fri, 01 Jun 2012 13:50:16 -0400, Walter Bright <newshound2@digitalmars.com> wrote:

> On 6/1/2012 5:29 AM, Steven Schveighoffer wrote:
>> No. What we need is a non-throwing version of malloc that returns NULL.
>
> We have it. It's called "malloc"!

Oh sorry, I meant *GC.malloc* :)

-Steve

Le 01/06/2012 02:57, Walter Bright a écrit :
> On 5/31/2012 2:23 AM, Lars T. Kyllingstad wrote:
>> On Thursday, 31 May 2012 at 02:18:22 UTC, Walter Bright wrote:
>>> A recoverable exception is NOT a logic bug in your program, which is
>>> why it is
>>> recoverable.
>>>
>>> If there is recovery possible from a particular assert error, then
>>> you are
>>> using asserts incorrectly.
>>
>> I think this is a key point. Asserts are there to verify and debug
>> program
>> logic, they are not part of the logic itself. They are a useful tool
>> for the
>> programmer, nothing more. Specifically, asserts are NOT an error handling
>> mechanism!
>
> Right. And I'd like to amplify that the asserts are also there to detect
> program faults hopefully before damage is done.
>
> If a program must continue even after it has failed, then you have a
> WRONGLY designed system.
>
> It is extremely important to understand this point if you are
> implementing any sort of critical software.

We are talking about runing scope statement and finally when unwiding the stack, not trying to continue the execution of the program.

This is, most of the time, the point of error/exceptions. You rarely recover from them in real life.