On 01/06/12 22:35, Walter Bright wrote:
On 6/1/2012 11:14 AM, deadalnix wrote:
We are talking about runing scope statement and finally when unwiding
the stack,
not trying to continue the execution of the program.
Which will be running arbitrary code not anticipated by the assert
failure, and
Le 01/06/2012 22:35, Walter Bright a écrit :
On 6/1/2012 11:14 AM, deadalnix wrote:
We are talking about runing scope statement and finally when unwiding
the stack,
not trying to continue the execution of the program.
Which will be running arbitrary code not anticipated by the assert
failure,
Walter Bright wrote:
On 5/31/2012 1:05 PM, Jens Mueller wrote:
Okay, let's assume I have separate processes maybe even processes on
different machines. In one process I get an error. Let's say I want to
trigger the other process that it restarts the process or just logs the
event whatever
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
Le 31/05/2012 21:47, Walter Bright a écrit :
On 5/31/2012 12:40 AM, Jens Mueller wrote:
How do I do a graceful shutdown if finally and scope is not guaranteed
to be executed? Assuming onAssertError, etc. is of no use because I need
to perform different shutdowns due to having different cases or
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
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 ...
On 6/1/12, Tobias Pankrath tob...@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
deadalnix deadal...@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
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
Le 01/06/2012 14:16, Tobias Pankrath a écrit :
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
On Friday, June 01, 2012 03:29:17 Walter Bright wrote:
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
On Friday, June 01, 2012 14:16:48 Tobias Pankrath wrote:
90% of null pointer dereferences are simple bugs not memory
corruption.
True, but it means that you have a logic bug, which means that your program is
in an invalid state anyway, and continuing could do who-knows-what. If you
want to
On Friday, June 01, 2012 20:14:45 deadalnix wrote:
We are talking about runing scope statement and finally when unwiding
the stack, not trying to continue the execution of the program.
Except that that _is_ continuing execution. It's only running cleanup code,
but if the program state is
On 6/1/2012 11:14 AM, deadalnix wrote:
We are talking about runing scope statement and finally when unwiding the stack,
not trying to continue the execution of the program.
Which will be running arbitrary code not anticipated by the assert failure, and
code that is highly unlikely to be
On 2012-05-30 23:16, Jonathan M Davis wrote:
You can catch them to print out additional information or whatever is useful
to generate more information about the Error. In fact, just what the Error
gives you is already more useful: message, file, line number, stack trace, etc.
That alone makes
On Thursday, May 31, 2012 08:26:18 Jacob Carlborg wrote:
On 2012-05-30 23:16, Jonathan M Davis wrote:
You can catch them to print out additional information or whatever is
useful to generate more information about the Error. In fact, just what
the Error gives you is already more useful:
On 2012-05-31 08:39, Jonathan M Davis wrote:
No. I haven't been arguing that. It's not particularly safe to catch Errors,
but they're catchable on purpose. It's catching and _handling_ an Error that's
generally a bad idea - that and continuing to execute after catching the Error
rather than
Walter Bright wrote:
On 5/30/2012 2:32 AM, Don Clugston wrote:
In fact, generally, the point of an AssertError is to prevent the program
from
entering an invalid state.
It's already in an invalid state when the assert fails, by definition.
It is not recoverable. The only option is a
Le 31/05/2012 04:10, Walter Bright a écrit :
On 5/30/2012 5:58 PM, Kapps wrote:
All code has bugs in it. It's nice being notified about it and all,
but if you
release a server application, and it crashes every single time it
encounters any
bug... well, your customers will not have a fun time.
Le 31/05/2012 03:06, Artur Skawina a écrit :
On 05/31/12 00:21, Jonathan M Davis wrote:
Now, it's perfectly possible to design code which never checks for null
pointers and if a null pointer is dereferenced throws an Exception and
attempts to recover from it (assuming that it's possible to
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 a custom paging mechanism).
2. program
Le 31/05/2012 00:21, Jonathan M Davis a écrit :
On Thursday, May 31, 2012 00:01:16 deadalnix wrote:
Le 30/05/2012 17:29, Don Clugston a écrit :
There's a big difference. A segfault is a machine error. The integrity
of the machine model has been violated, and the machine is in an
out-of-control
On Wed, 30 May 2012 22:36:50 +0100, Jonathan M Davis jmdavisp...@gmx.com
wrote:
In general, a segfault is definitely worse, but logic errors can_ be
just as bad in terms of the damage that they can do (especially in
cmparison with
segfaults caused by null pointers as opposed to those caused
On Thursday, 31 May 2012 at 02:18:22 UTC, Walter Bright wrote:
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 a custom paging
Le 31/05/2012 11:23, Lars T. Kyllingstad a écrit :
On Thursday, 31 May 2012 at 02:18:22 UTC, Walter Bright wrote:
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
On 5/31/2012 12:40 AM, Jens Mueller wrote:
How do I do a graceful shutdown if finally and scope is not guaranteed
to be executed? Assuming onAssertError, etc. is of no use because I need
to perform different shutdowns due to having different cases or if I
defined my own Error, let's say for some
On 5/31/2012 2:06 AM, deadalnix wrote:
A failure in database component should prevent me from close a network
connection properly in an unrelated part of the program.
It *is* related if the process space is shared. The correct way to do what
you're proposing is to make each component a
Walter Bright wrote:
On 5/31/2012 12:40 AM, Jens Mueller wrote:
How do I do a graceful shutdown if finally and scope is not guaranteed
to be executed? Assuming onAssertError, etc. is of no use because I need
to perform different shutdowns due to having different cases or if I
defined my own
On May 31, 2012, at 1:05 PM, Jens Mueller jens.k.muel...@gmx.de wrote:
Walter Bright wrote:
On 5/31/2012 12:40 AM, Jens Mueller wrote:
How do I do a graceful shutdown if finally and scope is not guaranteed
to be executed? Assuming onAssertError, etc. is of no use because I need
to perform
On 5/31/2012 1:05 PM, Jens Mueller wrote:
Okay, let's assume I have separate processes maybe even processes on
different machines. In one process I get an error. Let's say I want to
trigger the other process that it restarts the process or just logs the
event whatever makes sense.
How do I do
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
.
Let's now return to the real D world. Current implementation treats
Errors as Exceptions for now. Documentation keeps silence. All listed
can't be an error cases are Errors (and it's terrible).
So why do we has Exception/Error division in D? Because of nothrow.
Personally I don't need nothrow
Le 24/05/2012 20:39, Steven Schveighoffer a écrit :
I'd argue this is unrecoverable. Access Violation results from
corruption, and the damage has already been done. Even a null pointer
access can be the cause of previous corruption. There is no recovery
from memory corruption. There is no way to
Le 24/05/2012 21:33, Sean Kelly a écrit :
On May 24, 2012, at 11:39 AM, Steven Schveighoffer wrote:
On Thu, 24 May 2012 06:27:12 -0400, Denis
Shelomovskijverylonglogin@gmail.com wrote:
Let's talk about an abstract situation without caring about breaking existing
code, current docs,
Le 29/05/2012 18:53, Sean Kelly a écrit :
On May 24, 2012, at 11:50 PM, Jacob Carlborg wrote:
On 2012-05-24 21:33, Sean Kelly wrote:
This is a good point. OutOfMemory conditions aside, the only time I'd want to
recover from an Error condition was at the point the event occurred, not
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If an Error is truly unrecoverable (as they're generally supposed to be), then
what does it matter? Something fatal occured in your program, so it
terminates. Because it's
On 30.05.2012 12:33, deadalnix wrote:
Le 24/05/2012 21:33, Sean Kelly a écrit :
On May 24, 2012, at 11:39 AM, Steven Schveighoffer wrote:
On Thu, 24 May 2012 06:27:12 -0400, Denis
Shelomovskijverylonglogin@gmail.com wrote:
Let's talk about an abstract situation without caring about
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If an Error is truly unrecoverable (as they're generally supposed to be), then
what does it matter? Something fatal occured in
On Wednesday, May 30, 2012 11:32:00 Don Clugston wrote:
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If an Error is truly unrecoverable (as they're generally supposed
On 2012-05-30 12:59, Jonathan M Davis wrote:
Yes, which is why it's better to have an Error thrown rather than a halt
instruction be executed. But that doesn't mean that any attempt at cleanup is
any more valid.
If you're not supposed to be able to catch Errors then what's the
difference?
On 30.05.2012 17:28, Jacob Carlborg wrote:
On 2012-05-30 12:59, Jonathan M Davis wrote:
Yes, which is why it's better to have an Error thrown rather than a halt
instruction be executed. But that doesn't mean that any attempt at
cleanup is
any more valid.
If you're not supposed to be able to
Le 30/05/2012 11:32, Don Clugston a écrit :
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If an Error is truly unrecoverable (as they're generally supposed to
be), then
Le 30/05/2012 12:59, Jonathan M Davis a écrit :
And it's very valuable to log it properly.
Yes, which is why it's better to have an Error thrown rather than a halt
instruction be executed. But that doesn't mean that any attempt at cleanup is
any more valid.
Sorry but that is bullshit. What
On May 30, 2012, at 7:21 AM, deadalnix deadal...@gmail.com wrote:
Le 30/05/2012 12:59, Jonathan M Davis a écrit :
And it's very valuable to log it properly.
Yes, which is why it's better to have an Error thrown rather than a halt
instruction be executed. But that doesn't mean that any
On Wed, 30 May 2012 05:32:00 -0400, Don Clugston d...@nospam.com wrote:
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If an Error is truly unrecoverable (as they're
On May 30, 2012, at 8:05 AM, Steven Schveighoffer schvei...@yahoo.com wrote:
On Wed, 30 May 2012 05:32:00 -0400, Don Clugston d...@nospam.com wrote:
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and
On 30/05/12 12:59, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 11:32:00 Don Clugston wrote:
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If an Error is truly
Steven Schveighoffer wrote:
On Wed, 30 May 2012 05:32:00 -0400, Don Clugston d...@nospam.com wrote:
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If an Error is truly
On 30.05.2012 19:05, Steven Schveighoffer wrote:
On Wed, 30 May 2012 05:32:00 -0400, Don Clugston d...@nospam.com wrote:
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.
If
On Wed, 30 May 2012 11:47:34 -0400, Jens Mueller jens.k.muel...@gmx.de
wrote:
Steven Schveighoffer wrote:
case 2:
int main(string[] args)
{
writeln(invert(to!double(args[1])); // clearly a catchable error
}
This should be
int main(string[] args)
{
auto arg = to!double(args[1]);
Steven Schveighoffer wrote:
On Wed, 30 May 2012 11:47:34 -0400, Jens Mueller
jens.k.muel...@gmx.de wrote:
Steven Schveighoffer wrote:
case 2:
int main(string[] args)
{
writeln(invert(to!double(args[1])); // clearly a catchable error
}
This should be
int main(string[] args)
{
On Wednesday, May 30, 2012 15:28:22 Jacob Carlborg wrote:
On 2012-05-30 12:59, Jonathan M Davis wrote:
Yes, which is why it's better to have an Error thrown rather than a halt
instruction be executed. But that doesn't mean that any attempt at cleanup
is any more valid.
If you're not
On Wednesday, May 30, 2012 17:29:30 Don Clugston wrote:
On 30/05/12 12:59, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 11:32:00 Don Clugston wrote:
On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger
Le 30/05/2012 17:29, Don Clugston a écrit :
There's a big difference. A segfault is a machine error. The integrity
of the machine model has been violated, and the machine is in an
out-of-control state. In particular, the stack may be corrupted, so
stack unwinding may not be successful.
But, in
On Thursday, May 31, 2012 00:01:16 deadalnix wrote:
Le 30/05/2012 17:29, Don Clugston a écrit :
There's a big difference. A segfault is a machine error. The integrity
of the machine model has been violated, and the machine is in an
out-of-control state. In particular, the stack may be
On Wednesday, 30 May 2012 at 22:22:01 UTC, Jonathan M Davis wrote:
On Thursday, May 31, 2012 00:01:16 deadalnix wrote:
Most segfault are null deference or unintizialized pointer
deference.
Both are recoverable.
If you dereferenced a null pointer, it's a bug in your code.
Your code is
On Thursday, 31 May 2012 at 00:58:42 UTC, Kapps wrote:
All code has bugs in it. It's nice being notified about it and
all, but if you release a server application, and it crashes
every single time it encounters any bug... well, your customers
will not have a fun time.
Note that this
On 05/31/12 00:21, Jonathan M Davis wrote:
Now, it's perfectly possible to design code which never checks for null
pointers and if a null pointer is dereferenced throws an Exception and
attempts to recover from it (assuming that it's possible to detect the
dereference and throw at that
On May 30, 2012, at 5:58 PM, Kapps opantm2+s...@gmail.com wrote:
On Wednesday, 30 May 2012 at 22:22:01 UTC, Jonathan M Davis wrote:
On Thursday, May 31, 2012 00:01:16 deadalnix wrote:
Most segfault are null deference or unintizialized pointer deference.
Both are recoverable.
If you
On 5/30/2012 5:58 PM, Kapps wrote:
All code has bugs in it. It's nice being notified about it and all, but if you
release a server application, and it crashes every single time it encounters any
bug... well, your customers will not have a fun time.
The correct response to a server app crashing
On 5/30/2012 2:32 AM, Don Clugston wrote:
In fact, generally, the point of an AssertError is to prevent the program from
entering an invalid state.
It's already in an invalid state when the assert fails, by definition.
It is not recoverable. The only option is a more or less graceful
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 a custom paging mechanism).
2. program invariant errors (i.e. assert errors) --
On May 24, 2012, at 11:50 PM, Jacob Carlborg wrote:
On 2012-05-24 21:33, Sean Kelly wrote:
This is a good point. OutOfMemory conditions aside, the only time I'd want
to recover from an Error condition was at the point the event occurred, not
somewhere up the stack.
You never feel you
On 2012-05-24 21:33, Sean Kelly wrote:
This is a good point. OutOfMemory conditions aside, the only time I'd want to
recover from an Error condition was at the point the event occurred, not
somewhere up the stack.
You never feel you want to catch at the top level, print a sensible
error
).
So why do we has Exception/Error division in D? Because of nothrow.
Personally I don't need nothrow for that high cost of making D unusable for
me. Lets realize and solve Exception/Error problem and solve nothrow in the
second place.
Seems you already know this. Oops. I'm inclined
/Error division in D? Because of nothrow.
Personally I don't need nothrow for that high cost of making D unusable for
me. Lets realize and solve Exception/Error problem and solve nothrow in the
second place.
Seems you already know this. Oops. I'm inclined to agree, personally.
nothrow is less
On Thu, 24 May 2012 06:27:12 -0400, Denis Shelomovskij
verylonglogin@gmail.com wrote:
Let's talk about an abstract situation without caring about breaking
existing code, current docs, implementation etc.
Definitions:
* an Exception is something that tigers scope guards and executes
On May 24, 2012, at 11:39 AM, Steven Schveighoffer wrote:
On Thu, 24 May 2012 06:27:12 -0400, Denis Shelomovskij
verylonglogin@gmail.com wrote:
Let's talk about an abstract situation without caring about breaking
existing code, current docs, implementation etc.
Definitions:
* an
On Thu, 24 May 2012 15:33:07 -0400, Sean Kelly s...@invisibleduck.org
wrote:
On May 24, 2012, at 11:39 AM, Steven Schveighoffer wrote:
Can Out of memory be an Error? No, because e.g. if I read a user
file that require me to create a large array ( 100 MiB, e.g.) I don't
want to crash,
70 matches
Mail list logo
