On 31.05.2012 13:06, deadalnix wrote:
Le 31/05/2012 04:17, Walter Bright a écrit :
On 5/30/2012 8:05 AM, Steven Schveighoffer wrote:
I'd classify errors/exceptions into three categories:
1. corruption/segfault -- not recoverable under any reasonable
circumstances.
Special cases exist (such as
On Thursday, 31 May 2012 at 10:22:04 UTC, Dmitry Olshansky wrote:
Or the make it the default, but do _allow_ proper stack
unwinding (= usual cleanup) after call to crashOnError(false).
This would render nothrow useless, at least if the current
semantics of it (throwing Errors is acceptable) ar
On 31.05.2012 20:30, David Nadlinger wrote:
On Thursday, 31 May 2012 at 10:22:04 UTC, Dmitry Olshansky wrote:
Or the make it the default, but do _allow_ proper stack unwinding (=
usual cleanup) after call to crashOnError(false).
This would render nothrow useless, at least if the current semant
On 5/31/2012 3:22 AM, Dmitry Olshansky wrote:
On 31.05.2012 13:06, deadalnix wrote:
This is called failing gracefully. And this highly recommended, and you
KNOW that the system will fail at some point.
Exactly. + The point I tried to argue but it was apparently lost:
doing stack unwinding and
On 5/31/12 6:16 PM, Walter Bright wrote:
On 5/31/2012 3:22 AM, Dmitry Olshansky wrote:
On 31.05.2012 13:06, deadalnix wrote:
This is called failing gracefully. And this highly recommended, and you
KNOW that the system will fail at some point.
Exactly. + The point I tried to argue but it was a
Walter Bright wrote:
> On 5/31/2012 3:22 AM, Dmitry Olshansky wrote:
> >On 31.05.2012 13:06, deadalnix wrote:
> >>This is called failing gracefully. And this highly recommended, and you
> >>KNOW that the system will fail at some point.
> >
> >Exactly. + The point I tried to argue but it was apparen
On 01.06.2012 5:16, Walter Bright wrote:
On 5/31/2012 3:22 AM, Dmitry Olshansky wrote:
On 31.05.2012 13:06, deadalnix wrote:
This is called failing gracefully. And this highly recommended, and you
KNOW that the system will fail at some point.
Exactly. + The point I tried to argue but it was a
On 6/1/2012 1:48 AM, Dmitry Olshansky wrote:
On 01.06.2012 5:16, Walter Bright wrote:
On 5/31/2012 3:22 AM, Dmitry Olshansky wrote:
On 31.05.2012 13:06, deadalnix wrote:
This is called failing gracefully. And this highly recommended, and you
KNOW that the system will fail at some point.
Exac
On 6/1/2012 12:45 AM, Jens Mueller wrote:
This is perfectly valid when developing such critical systems. But
limiting D to effectively only allow developing such particular systems
cannot be the appropriate response. There are plenty of other systems
that do not operate in such a constrained envi
Le 01/06/2012 12:26, Walter Bright a écrit :
Except that you do not know why the arithmetic turned out wrong - it
could be the result of memory corruption.
Yes. wrong calculation often comes from memory corruption. Almost never
from programmer having screwed up in the said calculation.
It i
On Fri, 01 Jun 2012 04:48:27 -0400, Dmitry Olshansky
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
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:
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
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 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
On Fri, 01 Jun 2012 13:50:16 -0400, Walter Bright
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
On 06/01/12 19:59, Steven Schveighoffer wrote:
> On Fri, 01 Jun 2012 13:50:16 -0400, Walter Bright
> 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 m
Le 01/06/2012 12:15, Walter Bright a écrit :
On 6/1/2012 12:45 AM, Jens Mueller wrote:
This is perfectly valid when developing such critical systems. But
limiting D to effectively only allow developing such particular systems
cannot be the appropriate response. There are plenty of other systems
On Friday, June 01, 2012 14:00:01 deadalnix wrote:
> Le 01/06/2012 12:26, Walter Bright a écrit :
> > Except that you do not know why the arithmetic turned out wrong - it
> > could be the result of memory corruption.
>
> Yes. wrong calculation often comes from memory corruption. Almost never
> fro
On 01.06.2012 23:38, Jonathan M Davis wrote:
On Friday, June 01, 2012 14:00:01 deadalnix wrote:
Le 01/06/2012 12:26, Walter Bright a écrit :
Except that you do not know why the arithmetic turned out wrong - it
could be the result of memory corruption.
Yes. wrong calculation often comes from m
On 02.06.2012 0:06, Dmitry Olshansky wrote:
On 01.06.2012 23:38, Jonathan M Davis wrote:
On Friday, June 01, 2012 14:00:01 deadalnix wrote:
Le 01/06/2012 12:26, Walter Bright a écrit :
Except that you do not know why the arithmetic turned out wrong - it
could be the result of memory corruption
On 6/1/2012 1:06 PM, Dmitry Olshansky wrote:
Indeed it's quite bad to assume both extremes - either "oh, my god everything is
corrupted" or "blah, whatever, keep going". I thought D was trying to hold keep
reasonable compromises where possible.
D has a lot of bias towards being able to mechanic
On 6/1/2012 1:14 PM, Dmitry Olshansky wrote:
nothrow is not argument of itself. I've yet to see argument for
what it gives us that so important.
What nothrow gives is mechanically checkable documentation on the possible
results of a function.
> (C++ didn't have proper nothrow for ages, it d
On 02.06.2012 0:52, Walter Bright wrote:
On 6/1/2012 1:06 PM, Dmitry Olshansky wrote:
Indeed it's quite bad to assume both extremes - either "oh, my god
everything is
corrupted" or "blah, whatever, keep going". I thought D was trying to
hold keep
reasonable compromises where possible.
D has a
On Fri, 01 Jun 2012 19:43:06 +0200, Walter Bright
wrote:
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 sugges
On 6/1/2012 3:25 PM, Simen Kjaeraas wrote:
Autosave is a good idea. Autoloading last save upon resuming the game is not.
But saving the game before crashing, then explicitly telling the player that
something went wrong and the save might be corrupted and not to expect too much
from it, I think th
01.06.2012 21:43, Walter Bright написал:
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
On 01/06/12 12:26, Walter Bright wrote:
On 6/1/2012 1:48 AM, Dmitry Olshansky wrote:
On 01.06.2012 5:16, Walter Bright wrote:
On 5/31/2012 3:22 AM, Dmitry Olshansky wrote:
On 31.05.2012 13:06, deadalnix wrote:
This is called failing gracefully. And this highly recommended, and
you
KNOW that t
On Mon, 04 Jun 2012 06:20:56 -0400, Don Clugston wrote:
1. There exist cases where you cannot know why the assert failed.
2. Therefore you never know why an assert failed.
3. Therefore it is not safe to unwind the stack from a nothrow function.
Spot the fallacies.
The fallacy in moving from 2
On 04/06/12 21:29, Steven Schveighoffer wrote:
On Mon, 04 Jun 2012 06:20:56 -0400, Don Clugston wrote:
1. There exist cases where you cannot know why the assert failed.
2. Therefore you never know why an assert failed.
3. Therefore it is not safe to unwind the stack from a nothrow function.
S
On Tuesday, June 05, 2012 08:53:16 Don Clugston wrote:
> On 04/06/12 21:29, Steven Schveighoffer wrote:
> > On Mon, 04 Jun 2012 06:20:56 -0400, Don Clugston wrote:
> >> 1. There exist cases where you cannot know why the assert failed.
> >> 2. Therefore you never know why an assert failed.
> >> 3.
On 05/06/12 09:07, Jonathan M Davis wrote:
On Tuesday, June 05, 2012 08:53:16 Don Clugston wrote:
On 04/06/12 21:29, Steven Schveighoffer wrote:
On Mon, 04 Jun 2012 06:20:56 -0400, Don Clugston wrote:
1. There exist cases where you cannot know why the assert failed.
2. Therefore you never kno
On 05.06.2012 15:57, Don Clugston wrote:
On 05/06/12 09:07, Jonathan M Davis wrote:
On Tuesday, June 05, 2012 08:53:16 Don Clugston wrote:
On 04/06/12 21:29, Steven Schveighoffer wrote:
On Mon, 04 Jun 2012 06:20:56 -0400, Don Clugston wrote:
1. There exist cases where you cannot know why the
On Tuesday, June 05, 2012 13:57:14 Don Clugston wrote:
> On 05/06/12 09:07, Jonathan M Davis wrote:
> > On Tuesday, June 05, 2012 08:53:16 Don Clugston wrote:
> >> On 04/06/12 21:29, Steven Schveighoffer wrote:
> >>> On Mon, 04 Jun 2012 06:20:56 -0400, Don Clugston wrote:
> 1. There exist cas
On Jun 5, 2012, at 8:44 AM, Jonathan M Davis wrote:
>
> In many cases, it's probably fine, but if the program is in a bad enough
> state
> that an Error is thrown, then you can't know for sure that any particular
> such
> block will execute properly (memory corruption being the extreme case),
Le 04/06/2012 21:29, Steven Schveighoffer a écrit :
On Mon, 04 Jun 2012 06:20:56 -0400, Don Clugston wrote:
1. There exist cases where you cannot know why the assert failed.
2. Therefore you never know why an assert failed.
3. Therefore it is not safe to unwind the stack from a nothrow functio
On Friday, 1 June 2012 at 12:29:27 UTC, Steven Schveighoffer
wrote:
On Fri, 01 Jun 2012 04:48:27 -0400, Dmitry Olshansky
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
On Wednesday, June 06, 2012 11:13:39 Lars T. Kyllingstad wrote:
> On Friday, 1 June 2012 at 12:29:27 UTC, Steven Schveighoffer
>
> wrote:
> > On Fri, 01 Jun 2012 04:48:27 -0400, Dmitry Olshansky
> >
> > wrote:
> >> I don't agree that OutOfMemory is critical:
> >>--> make it an exception ?
>
On Wed, 06 Jun 2012 05:13:39 -0400, Lars T. Kyllingstad
wrote:
On Friday, 1 June 2012 at 12:29:27 UTC, Steven Schveighoffer wrote:
On Fri, 01 Jun 2012 04:48:27 -0400, Dmitry Olshansky
wrote:
I don't agree that OutOfMemory is critical:
--> make it an exception ?
No. What we ne
On 05/06/12 17:44, Jonathan M Davis wrote:
On Tuesday, June 05, 2012 13:57:14 Don Clugston wrote:
On 05/06/12 09:07, Jonathan M Davis wrote:
On Tuesday, June 05, 2012 08:53:16 Don Clugston wrote:
On 04/06/12 21:29, Steven Schveighoffer wrote:
On Mon, 04 Jun 2012 06:20:56 -0400, Don Clugston
Le 06/06/2012 11:13, Lars T. Kyllingstad a écrit :
On Friday, 1 June 2012 at 12:29:27 UTC, Steven Schveighoffer wrote:
On Fri, 01 Jun 2012 04:48:27 -0400, Dmitry Olshansky
wrote:
I don't agree that OutOfMemory is critical:
--> make it an exception ?
No. What we need is a non-throwing versio
Le 05/06/2012 18:21, Sean Kelly a écrit :
On Jun 5, 2012, at 8:44 AM, Jonathan M Davis wrote:
In many cases, it's probably fine, but if the program is in a bad enough state
that an Error is thrown, then you can't know for sure that any particular such
block will execute properly (memory corrup
On Jun 6, 2012, at 9:45 AM, deadalnix wrote:
> Le 05/06/2012 18:21, Sean Kelly a écrit :
>> On Jun 5, 2012, at 8:44 AM, Jonathan M Davis wrote:
>>>
>>> In many cases, it's probably fine, but if the program is in a bad enough
>>> state
>>> that an Error is thrown, then you can't know for sure th
Yes, that's what I had in mind when I renamed topic to "runtime hook for
Crash on Error". Default should be treat Error as just another type of
throwable that is logically not caught by catch(Exception).
--
Dmitry Olshansky
On Wednesday, 6 June 2012 at 13:26:09 UTC, Steven Schveighoffer
wrote:
On Wed, 06 Jun 2012 05:13:39 -0400, Lars T. Kyllingstad
wrote:
On Friday, 1 June 2012 at 12:29:27 UTC, Steven Schveighoffer
wrote:
On Fri, 01 Jun 2012 04:48:27 -0400, Dmitry Olshansky
wrote:
I don't agree that OutOfMe
On Wednesday, 6 June 2012 at 09:38:35 UTC, Jonathan M Davis wrote:
On Wednesday, June 06, 2012 11:13:39 Lars T. Kyllingstad wrote:
On Friday, 1 June 2012 at 12:29:27 UTC, Steven Schveighoffer
wrote:
> On Fri, 01 Jun 2012 04:48:27 -0400, Dmitry Olshansky
>
> wrote:
>> I don't agree that OutOf
assuming the default behavior.
Yes, that's what I had in mind when I renamed topic to "runtime hook for
Crash on Error". Default should be treat Error as just another type of
throwable that is logically not caught by catch(Exception).
A better alternative is the condition system, i
On Wednesday, 6 June 2012 at 09:38:35 UTC, Jonathan M Davis wrote:
On Wednesday, June 06, 2012 11:13:39 Lars T. Kyllingstad wrote:
On Friday, 1 June 2012 at 12:29:27 UTC, Steven Schveighoffer
wrote:
> On Fri, 01 Jun 2012 04:48:27 -0400, Dmitry Olshansky
>
> wrote:
>> I don't agree that OutOf
On Wednesday, June 06, 2012 19:40:03 Lars T. Kyllingstad wrote:
> On Wednesday, 6 June 2012 at 09:38:35 UTC, Jonathan M Davis wrote:
> > On Wednesday, June 06, 2012 11:13:39 Lars T. Kyllingstad wrote:
> >> On Friday, 1 June 2012 at 12:29:27 UTC, Steven Schveighoffer
> >>
> >> wrote:
> >> > On Fri,
On Wednesday, June 06, 2012 19:22:13 Lars T. Kyllingstad wrote:
> On Wednesday, 6 June 2012 at 09:38:35 UTC, Jonathan M Davis wrote:
> > On Wednesday, June 06, 2012 11:13:39 Lars T. Kyllingstad wrote:
> >> On Friday, 1 June 2012 at 12:29:27 UTC, Steven Schveighoffer
> >>
> >> wrote:
> >> > On Fri,
On 06/06/2012 07:18 PM, Lars T. Kyllingstad wrote:
On Wednesday, 6 June 2012 at 13:26:09 UTC, Steven Schveighoffer wrote:
On Wed, 06 Jun 2012 05:13:39 -0400, Lars T. Kyllingstad
wrote:
On Friday, 1 June 2012 at 12:29:27 UTC, Steven Schveighoffer wrote:
On Fri, 01 Jun 2012 04:48:27 -0400, Dmi
On Wednesday, 6 June 2012 at 18:11:36 UTC, Jonathan M Davis wrote:
On Wednesday, June 06, 2012 19:40:03 Lars T. Kyllingstad wrote:
On Wednesday, 6 June 2012 at 09:38:35 UTC, Jonathan M Davis
wrote:
> On Wednesday, June 06, 2012 11:13:39 Lars T. Kyllingstad
> wrote:
>> On Friday, 1 June 2012 at
On Wednesday, 6 June 2012 at 18:11:42 UTC, Jonathan M Davis wrote:
On Wednesday, June 06, 2012 19:22:13 Lars T. Kyllingstad wrote:
On Wednesday, 6 June 2012 at 09:38:35 UTC, Jonathan M Davis
wrote:
> On Wednesday, June 06, 2012 11:13:39 Lars T. Kyllingstad
> wrote:
>> On Friday, 1 June 2012 at
On Wednesday, June 06, 2012 22:47:55 Lars T. Kyllingstad wrote:
> On Wednesday, 6 June 2012 at 18:11:36 UTC, Jonathan M Davis wrote:
> > On Wednesday, June 06, 2012 19:40:03 Lars T. Kyllingstad wrote:
> >> On Wednesday, 6 June 2012 at 09:38:35 UTC, Jonathan M Davis
> >>
> >> wrote:
> >> > On Wedne
On Wednesday, 6 June 2012 at 19:27:31 UTC, Timon Gehr wrote:
On 06/06/2012 07:18 PM, Lars T. Kyllingstad wrote:
Besides OutOfMemoryError, I can only think of two other Errors
that
would make this a hassle: AssertError and RangeError. However,
both of
these signify problems with the program logi
On 06/06/2012 11:04 PM, Lars T. Kyllingstad wrote:
On Wednesday, 6 June 2012 at 19:27:31 UTC, Timon Gehr wrote:
On 06/06/2012 07:18 PM, Lars T. Kyllingstad wrote:
Besides OutOfMemoryError, I can only think of two other Errors that
would make this a hassle: AssertError and RangeError. However, b
On Wednesday, 6 June 2012 at 21:35:15 UTC, Timon Gehr wrote:
On 06/06/2012 11:04 PM, Lars T. Kyllingstad wrote:
On Wednesday, 6 June 2012 at 19:27:31 UTC, Timon Gehr wrote:
On 06/06/2012 07:18 PM, Lars T. Kyllingstad wrote:
Besides OutOfMemoryError, I can only think of two other
Errors that
wo
On Wednesday, 6 June 2012 at 21:05:51 UTC, Jonathan M Davis wrote:
On Wednesday, June 06, 2012 22:47:55 Lars T. Kyllingstad wrote:
On Wednesday, 6 June 2012 at 18:11:36 UTC, Jonathan M Davis
wrote:
> On Wednesday, June 06, 2012 19:40:03 Lars T. Kyllingstad
> wrote:
>> On Wednesday, 6 June 2012
On 06/07/2012 12:11 AM, Lars T. Kyllingstad wrote:
On Wednesday, 6 June 2012 at 21:05:51 UTC, Jonathan M Davis wrote:
...
Having a mechanism which allows you to allocate without throwing OOM
is great
for the cases where someone actually needs, it but I'm _completely_
against
requiring it anywher
59 matches
Mail list logo
