On Tue, 07 Oct 2014 14:39:06 +0100, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 10/7/14, 12:36 AM, monarch_dodra wrote:
Hum... But arguably, that's just exception chaining happening. Do you
have any examples of someone actually dealing with all the exceptions
in a chain in a
On Tuesday, 7 October 2014 at 03:19:06 UTC, Andrei Alexandrescu
wrote:
Note that if we reverse the chaining (like java does), then the
loop problem mostly disappear. It is still possible to create
it,
you you got to actively look for it.
I knew Python has chaining but not Java. Got a
On Monday, 6 October 2014 at 16:59:35 UTC, Andrei Alexandrescu
wrote:
Whenever an exception is converted to a string, the chained
exceptions should be part of it too.
On Monday, 6 October 2014 at 17:12:00 UTC, Jakob Ovrum wrote:
However, the whole point is implicit chaining, which is where
On Tuesday, 7 October 2014 at 07:36:56 UTC, monarch_dodra wrote:
happening. Do you have any examples of someone actually
dealing with all the exceptions in a chain in a catch, or
actually using the information in a manner that is more than
just printing?
I've never used it myself in real
On 10/05/2014 08:01 AM, ketmar via Digitalmars-d wrote:
On Sat, 04 Oct 2014 14:48:26 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
There's no interesting way to check this because functions don't list
the exceptions they might throw (like Java does). -- Andrei
On 10/7/14, 12:36 AM, monarch_dodra wrote:
Hum... But arguably, that's just exception chaining happening. Do you
have any examples of someone actually dealing with all the exceptions
in a chain in a catch, or actually using the information in a manner
that is more than just printing?
No. But
On Tue, 07 Oct 2014 14:59:52 +0200
Timon Gehr via Digitalmars-d digitalmars-d@puremagic.com wrote:
What's the point anyway?
non-final try/catch will not make function nothrow.
signature.asc
Description: PGP signature
On 10/07/2014 03:57 PM, ketmar via Digitalmars-d wrote:
On Tue, 07 Oct 2014 14:59:52 +0200
Timon Gehr via Digitalmars-d digitalmars-d@puremagic.com wrote:
What's the point anyway?
non-final try/catch will not make function nothrow.
void doStuff(){ }
void main() nothrow{
try{
On Tue, 07 Oct 2014 16:08:33 +0200
Timon Gehr via Digitalmars-d digitalmars-d@puremagic.com wrote:
What's the point anyway?
non-final try/catch will not make function nothrow.
i'm talking about my proposal, where non-final try/catch will not make
function nothrow, only 'final try' will do.
On 10/07/2014 04:23 PM, ketmar via Digitalmars-d wrote:
On Tue, 07 Oct 2014 16:08:33 +0200
Timon Gehr via Digitalmars-d digitalmars-d@puremagic.com wrote:
What's the point anyway?
non-final try/catch will not make function nothrow.
import core.exception;
void doStuff(){ }
void main()
On Tue, 07 Oct 2014 16:34:12 +0200
Timon Gehr via Digitalmars-d digitalmars-d@puremagic.com wrote:
import core.exception;
void doStuff(){ }
void main() nothrow{
try{ doStuff(); }
catch(UnicodeException){ }
}
Error: function D main 'main' is nothrow yet may throw
that's not
On Monday, 6 October 2014 at 00:29:20 UTC, deadalnix wrote:
I know of several cases where this trick was used and it turned
out horribly wrong. OOE is NOT recoverable. It may be in some
cases, and you can use trick to make them recoverable in more
cases, like the one mentioned, but ultimately,
On Monday, 6 October 2014 at 02:35:52 UTC, Shammah Chancellor
wrote:
It doesn't catch the error. Propigation should continue as
normal.
Right, it only intercepts, cleanups, and rethrows. But the
argument is that even that shouldn't happen, as you aren't sure
the cleanup code is still
On 10/5/2014 10:09 AM, Dicebot wrote:
On Sunday, 5 October 2014 at 17:03:07 UTC, Andrei Alexandrescu wrote:
On 10/5/14, 9:42 AM, Dicebot wrote:
On Sunday, 5 October 2014 at 16:30:47 UTC, Ola Fosheim Grøstad wrote:
Does D have exception chaining?
Yes.
On Monday, 6 October 2014 at 07:28:22 UTC, Walter Bright wrote:
FWIW, I'm skeptical as well of the value of chaining relative
to its cost in complexity.
Python 3 has two fields: __cause__ and __context__.
The cause field is used for explicit chaining on re-throws. Can
be useful for
On 10/6/14, 12:27 AM, Walter Bright wrote:
On 10/5/2014 10:09 AM, Dicebot wrote:
On Sunday, 5 October 2014 at 17:03:07 UTC, Andrei Alexandrescu wrote:
On 10/5/14, 9:42 AM, Dicebot wrote:
On Sunday, 5 October 2014 at 16:30:47 UTC, Ola Fosheim Grøstad wrote:
Does D have exception chaining?
On Monday, 6 October 2014 at 13:48:07 UTC, Andrei Alexandrescu
wrote:
On 10/6/14, 12:27 AM, Walter Bright wrote:
On 10/5/2014 10:09 AM, Dicebot wrote:
On Sunday, 5 October 2014 at 17:03:07 UTC, Andrei
Alexandrescu wrote:
On 10/5/14, 9:42 AM, Dicebot wrote:
On Sunday, 5 October 2014 at
On 10/4/14 2:45 PM, Shammah Chancellor wrote:
int main()
{
scope(exit) return 0;
assert(false, whoops!);
}
The above smells to me like it should be invalid. Specifically, the
scope(exit) line by itself.
If you want to catch and not propagate an error, you need to use
try/catch
On 10/6/14, 7:24 AM, monarch_dodra wrote:
If your catch throws an exception, then the new exception simply
squashes replaces the old one:
//
catch (Exception e)
{
thisMightThrow(); //Lose e here
throw e;
}
//
That's code under library/user control, I'm talking about the
On Monday, 6 October 2014 at 14:54:21 UTC, Andrei Alexandrescu
wrote:
On 10/6/14, 7:24 AM, monarch_dodra wrote:
If your catch throws an exception, then the new exception
simply
squashes replaces the old one:
//
catch (Exception e)
{
thisMightThrow(); //Lose e here
throw e;
}
On 10/6/14, 9:55 AM, monarch_dodra wrote:
On Monday, 6 October 2014 at 14:54:21 UTC, Andrei Alexandrescu wrote:
On 10/6/14, 7:24 AM, monarch_dodra wrote:
If your catch throws an exception, then the new exception simply
squashes replaces the old one:
//
catch (Exception e)
{
On Monday, 6 October 2014 at 16:55:39 UTC, monarch_dodra wrote:
For the sake of argument, do you have any examples where a
program has used chaining?
I use explicit chaining in a couple of my libraries, i.e. code
like:
---
try foo();
catch(FooException e)
{
throw new
On Monday, 6 October 2014 at 13:48:07 UTC, Andrei Alexandrescu
wrote:
It's one of those designs in which there's little room to turn.
We wanted to (a) allow destructors to throw, (b) conserve
information. Offering access to all exceptions caught was a
natural consequence. -- Andrei
Note that
On Monday, 6 October 2014 at 17:12:00 UTC, Jakob Ovrum wrote:
On Monday, 6 October 2014 at 16:55:39 UTC, monarch_dodra wrote:
For the sake of argument, do you have any examples where a
program has used chaining?
I use explicit chaining in a couple of my libraries, i.e. code
like:
---
try
On 10/6/14, 7:25 PM, deadalnix wrote:
On Monday, 6 October 2014 at 13:48:07 UTC, Andrei Alexandrescu
wrote:
It's one of those designs in which there's little room to turn. We
wanted to (a) allow destructors to throw, (b) conserve information.
Offering access to all exceptions caught was a
On Sat, 04 Oct 2014 14:48:26 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
There's no interesting way to check this because functions don't list
the exceptions they might throw (like Java does). -- Andrei
sure there is no way to check. this 'final try' helper
On Saturday, 4 October 2014 at 18:42:05 UTC, Shammah Chancellor
wrote:
Didn't miss anything. I was responding to Andrei such that he
might think it's not so straightforward to evaluate that code.
I am with you on this. It was my original complaint months
ago that resulted in this being
On Sun, 05 Oct 2014 11:28:59 +
monarch_dodra via Digitalmars-d digitalmars-d@puremagic.com wrote:
In theory, you should seldom ever catch Errors. I don't
understand why scope(exit) are catching them.
'cause scope(exit) keeps the promise to execute cleanup code before
exiting code block?
On Sunday, 5 October 2014 at 12:36:30 UTC, ketmar via
Digitalmars-d wrote:
On Sun, 05 Oct 2014 11:28:59 +
monarch_dodra via Digitalmars-d digitalmars-d@puremagic.com
wrote:
In theory, you should seldom ever catch Errors. I don't
understand why scope(exit) are catching them.
'cause
On Sun, 05 Oct 2014 14:53:37 +
monarch_dodra via Digitalmars-d digitalmars-d@puremagic.com wrote:
Promises hold provided the precondition your program is in a
valid state. Having an Error invalidates that precondition, hence
voids that promise.
so Error should not be catchable and should
On Sunday, 5 October 2014 at 15:03:08 UTC, ketmar via
Digitalmars-d wrote:
On Sun, 05 Oct 2014 14:53:37 +
monarch_dodra via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Promises hold provided the precondition your program is in a
valid state. Having an Error invalidates that
On Sunday, 5 October 2014 at 15:03:08 UTC, ketmar via
Digitalmars-d wrote:
so Error should not be catchable and should crash immidiately,
without
any unwinding. as long as Errors are just another kind of
exception,
the promise must be kept.
I find it strange if you cannot recover from
On Sun, 05 Oct 2014 16:33:48 +
monarch_dodra via Digitalmars-d digitalmars-d@puremagic.com wrote:
Errors aren't Exceptions. They make no promises.
if it looks like a duck, if it quacks like a duck, if it can be catched
like a duck... it's a duck. that's not me who titled exception base
class
On Sunday, 5 October 2014 at 16:30:47 UTC, Ola Fosheim Grøstad
wrote:
Does D have exception chaining?
Yes. http://dlang.org/phobos/object.html#.Throwable.next
Though it seems to do more harm then good so far.
On Sunday, 5 October 2014 at 16:42:24 UTC, ketmar via
Digitalmars-d wrote:
it does
unwinding?
It is not guaranteed by spec (I guess this was added to allow
assert(0) to be converted into HLT instruction) though in most
cases it does. Neither it is guaranteed to run destructors of
RAII
On Sun, 05 Oct 2014 16:47:26 +
Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote:
Pretty much only reason `Error` is not equivalent to plain
`abort` call is to allow some last resort debbugging dump and
provide more meaningful information about the failure.
than it was done
On 10/5/14, 9:42 AM, Dicebot wrote:
On Sunday, 5 October 2014 at 16:30:47 UTC, Ola Fosheim Grøstad wrote:
Does D have exception chaining?
Yes. http://dlang.org/phobos/object.html#.Throwable.next
Though it seems to do more harm then good so far.
What harm does it do? -- Andrei
On Sunday, 5 October 2014 at 17:03:07 UTC, Andrei Alexandrescu
wrote:
On 10/5/14, 9:42 AM, Dicebot wrote:
On Sunday, 5 October 2014 at 16:30:47 UTC, Ola Fosheim Grøstad
wrote:
Does D have exception chaining?
Yes. http://dlang.org/phobos/object.html#.Throwable.next
Though it seems to do more
On Sunday, 5 October 2014 at 16:42:38 UTC, Dicebot wrote:
Yes. http://dlang.org/phobos/object.html#.Throwable.next
Though it seems to do more harm then good so far.
Hm, so the next field is used for two different purposes? Both
for capturing the original exception on a rethrow and for
On Sunday, 5 October 2014 at 16:30:47 UTC, Ola Fosheim Grøstad
wrote:
On Sunday, 5 October 2014 at 15:03:08 UTC, ketmar via
Digitalmars-d wrote:
so Error should not be catchable and should crash immidiately,
without
any unwinding. as long as Errors are just another kind of
exception,
the
On 2014-10-05 11:28:59 +, monarch_dodra said:
On Saturday, 4 October 2014 at 18:42:05 UTC, Shammah Chancellor wrote:
Didn't miss anything. I was responding to Andrei such that he might
think it's not so straightforward to evaluate that code.
I am with you on this. It was my original
On Saturday, 4 October 2014 at 05:54:20 UTC, ketmar via
Digitalmars-d wrote:,
'cause `MyWrapper` promises to nothrow. you can't make such
promise for
try-block.
If finally does imply nothrow then the try-block implies it too.
No difference from a wrapper.
i.e. `MyWrapper` promises that the
On Sat, Oct 04, 2014 at 01:08:38AM -0400, Shammah Chancellor via Digitalmars-d
wrote:
On 2014-10-03 19:35:31 +, Andrei Alexandrescu said:
[...]
Worse yet:
// What does this function do? What *should* it do??
int func() {
scope(success)
throw new
On Sat, 04 Oct 2014 05:58:47 +
Ola Fosheim Grostad via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Nah, it is a matter of ad hoc design and implementation that
needs more rigour.
something like 'final try' can be fun. 'try' says that it can catch
only some kinds of exceptions, and
On Saturday, 4 October 2014 at 06:28:52 UTC, ketmar via
Digitalmars-d wrote:
do you mind to fill ER? it will be rejected, but hey, we can
start a
little competiion here! ;-)
Triathlon isn't really my thing...
So I am only participating in the patching-competition. :-)
On 2014-10-04 06:09:39 +, H. S. Teoh via Digitalmars-d said:
On Sat, Oct 04, 2014 at 01:08:38AM -0400, Shammah Chancellor via
Digitalmars-d wrote:
On 2014-10-03 19:35:31 +, Andrei Alexandrescu said:
[...]
Worse yet:
// What does this function do? What *should* it do??
On 10/3/14, 8:01 PM, deadalnix wrote:
On Friday, 3 October 2014 at 19:35:21 UTC, Andrei Alexandrescu wrote:
I guess I'm convinced it adds more complication than expressiveness!
True for return, but throw is a stupid limitation( as it do not prevent
the scope to throw at all, simply forc to
On 10/3/14, 11:28 PM, ketmar via Digitalmars-d wrote:
On Sat, 04 Oct 2014 05:58:47 +
Ola Fosheim Grostad via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Nah, it is a matter of ad hoc design and implementation that
needs more rigour.
something like 'final try' can be fun. 'try' says
On 2014-10-04 21:44:43 +, Andrei Alexandrescu said:
On 10/3/14, 8:01 PM, deadalnix wrote:
On Friday, 3 October 2014 at 19:35:21 UTC, Andrei Alexandrescu wrote:
I guess I'm convinced it adds more complication than expressiveness!
True for return, but throw is a stupid limitation( as it
On Friday, 3 October 2014 at 04:52:24 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 03 Oct 2014 04:40:53 +
deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote:
The throw thing is rather stupid, as the scope statement can
call arbitrary function that can itself throw.
that's why
On 10/2/14, 8:23 PM, Ali Çehreli wrote:
A scope(exit) or scope(success) statement may not exit with a throw,
goto, break, continue, or return; nor may it be entered with a goto.
Seems to me all these restrictions should be lifted. -- Andrei
On Fri, Oct 03, 2014 at 10:50:39AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 10/2/14, 8:23 PM, Ali Çehreli wrote:
A scope(exit) or scope(success) statement may not exit with a throw,
goto, break, continue, or return; nor may it be entered with a goto.
Seems to me all these
On 10/3/14, 11:18 AM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Oct 03, 2014 at 10:50:39AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
On 10/2/14, 8:23 PM, Ali Çehreli wrote:
A scope(exit) or scope(success) statement may not exit with a throw,
goto, break, continue, or return; nor
On Friday, 3 October 2014 at 17:50:29 UTC, Andrei Alexandrescu
wrote:
On 10/2/14, 8:23 PM, Ali Çehreli wrote:
A scope(exit) or scope(success) statement may not exit with a
throw,
goto, break, continue, or return; nor may it be entered with a
goto.
Seems to me all these restrictions should be
On Friday, 3 October 2014 at 19:35:21 UTC, Andrei Alexandrescu
wrote:
I guess I'm convinced it adds more complication than
expressiveness!
True for return, but throw is a stupid limitation( as it do not
prevent the scope to throw at all, simply forc to hide it, which
is only worse).
On Sat, 04 Oct 2014 03:01:14 +
deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote:
True for return, but throw is a stupid limitation( as it do not
prevent the scope to throw at all, simply forc to hide it, which
is only worse).
scope(exit) {
some-cleanup-code
deadalnix deadal...@gmail.com wrote:
On Friday, 3 October 2014 at 19:35:21 UTC, Andrei Alexandrescu wrote:
I guess I'm convinced it adds more complication than expressiveness!
True for return, but throw is a stupid limitation( as it do not prevent
the scope to throw at all, simply forc to
On Saturday, 4 October 2014 at 03:21:23 UTC, ketmar via
Digitalmars-d wrote:
scope(exit) {
some-cleanup-code
thisCanThrow();
some-more-cleanup-code
}
and what we should do with some-more-cleanup-code if
thisCanThrow
throws?
It is tricky if the throw implies that the caller
On Sat, 04 Oct 2014 03:46:35 +
Ola Fosheim Grostad via Digitalmars-d digitalmars-d@puremagic.com
wrote:
It is tricky if the throw implies that the caller to the cleanup
should retry because of a timeout/deadlock
it shouldn't. exception during cleanup means oh, i can't! i
On Saturday, 4 October 2014 at 03:21:23 UTC, ketmar via
Digitalmars-d wrote:
On Sat, 04 Oct 2014 03:01:14 +
deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote:
True for return, but throw is a stupid limitation( as it do
not prevent the scope to throw at all, simply forc to hide
On Saturday, 4 October 2014 at 04:29:06 UTC, ketmar via
Digitalmars-d wrote:
It is tricky if the throw implies that the caller to the
cleanup should retry because of a timeout/deadlock
it shouldn't. exception during cleanup means oh, i can't! i
really-really-really can't!, not ok, i'm busy, try
On Sat, 04 Oct 2014 04:54:38 +
Ola Fosheim Grostad via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Should or should not, you have to make do with what you get from
libraries.
wrapper is the answer.
Network being temporarily unavailable is a good reason
to throw when freeing a
On 2014-10-03 19:35:31 +, Andrei Alexandrescu said:
Better yet:
int func() {
scope(exit)
return 1;
scope(exit)
return 2;
return 0;
}
2
That should return 1 as the return 1 is
On 2014-10-03 20:18:44 +, David Nadlinger said:
On Friday, 3 October 2014 at 17:50:29 UTC, Andrei Alexandrescu wrote:
On 10/2/14, 8:23 PM, Ali Çehreli wrote:
A scope(exit) or scope(success) statement may not exit with a throw,
goto, break, continue, or return; nor may it be entered with a
On Saturday, 4 October 2014 at 04:47:46 UTC, deadalnix wrote:
Also, we have exception chaining, so that's all good.
Exception chaining just means that you build a linked list
recording the history when rethrowing a different type of
exception in a catch block. How does that help?
On Sat, 04 Oct 2014 04:47:44 +
deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote:
Write this in sepeareted scope statement?. problem solved.
i don't agree. it makes excessive noise for nothing. and it breaking
the implied promise all cleanup code will be executed on exit. it's
On Saturday, 4 October 2014 at 05:05:00 UTC, ketmar via
Digitalmars-d wrote:
On Sat, 04 Oct 2014 04:54:38 +
Ola Fosheim Grostad via Digitalmars-d
digitalmars-d@puremagic.com
wrote:
Should or should not, you have to make do with what you get
from libraries.
wrapper is the answer.
I
On Sat, 04 Oct 2014 05:22:10 +
Ola Fosheim Grostad via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Should or should not, you have to make do with what you get
from libraries.
wrapper is the answer.
I dont disagree, but the language spec says that you cannot catch
in a finally
On Saturday, 4 October 2014 at 05:33:29 UTC, ketmar via
Digitalmars-d wrote:
void myWrapper () nothrow {
try throwItAtMe(); catch (LovelyException) {}
}
scope(exit) myWrapper();
this is perfectly legal, as we not cathcing anything in
scope(exit).
Why should these two cases be
On Sat, 04 Oct 2014 05:37:14 +
Ola Fosheim Grostad via Digitalmars-d digitalmars-d@puremagic.com
wrote:
Why should these two cases be treated different? Makes no sense,
'cause `MyWrapper` promises to nothrow. you can't make such promise for
try-block.
i.e. `MyWrapper` promises that the only
Per the documentation (http://dlang.org/statement.html) scope
statements are not precluded from returning, but DMD does not allow for
it. Should the documentation be updated?
-S
On 10/02/2014 07:17 PM, Shammah Chancellor wrote:
Per the documentation (http://dlang.org/statement.html) scope statements
are not precluded from returning, but DMD does not allow for it.
Should the documentation be updated?
-S
Can you show a piece of code. The following quote says may not
On 2014-10-03 03:23:24 +, Ali Çehreli said:
A scope(exit) or scope(success) statement may not exit with a throw,
goto, break, continue, or return; nor may it be entered with a goto
Derp. I did not see that. I was looking at the grammar on the top.
On Friday, 3 October 2014 at 03:23:25 UTC, Ali Çehreli wrote:
On 10/02/2014 07:17 PM, Shammah Chancellor wrote:
Per the documentation (http://dlang.org/statement.html) scope
statements
are not precluded from returning, but DMD does not allow for
it.
Should the documentation be updated?
-S
On Fri, 03 Oct 2014 04:40:53 +
deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote:
The throw thing is rather stupid, as the scope statement can call
arbitrary function that can itself throw.
that's why you'd better use collectException() there, i presume. ;-)
btw: shouldn't
75 matches
Mail list logo
