View mode: basic / threaded / horizontal-split · Log in · Help
June 01, 2012
Re: Exception/Error division in D
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.
June 01, 2012
Re: runtime hook for Crash on Error
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
June 01, 2012
Re: runtime hook for Crash on Error
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
June 01, 2012
Re: Exception/Error division in D
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).
June 01, 2012
Re: Exception/Error division in D
"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.
June 01, 2012
Re: runtime hook for Crash on Error
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.
June 01, 2012
Re: runtime hook for Crash on Error
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.)
June 01, 2012
Re: runtime hook for Crash on Error
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"!

:-)
June 01, 2012
Re: runtime hook for Crash on Error
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
June 01, 2012
Re: Exception/Error division in D
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.
4 5 6 7 8 9 10 11 12
Top | Discussion index | About this forum | D home