I am obviously in favor of simply calling recurrent mutable
exception chains illegal (probably even immutable ones until we
fix const correctness of druntime exception handling).
Reason is simple : it doesn't require any changes in existing
code and is exactly the way we already do it in
On Friday, 19 September 2014 at 07:57:24 UTC, Dicebot wrote:
I am obviously in favor of simply calling recurrent mutable
exception chains illegal (probably even immutable ones until we
fix const correctness of druntime exception handling).
Reason is simple : it doesn't require any changes in
On Friday, 19 September 2014 at 11:36:29 UTC, Jakob Ovrum wrote:
That might be sufficient for a particular application like
Sociomantic's, but it's not sufficient for library code in
general. Such chains aren't logic errors and can easily occur
in the wild.
The point of exception chaining is
13-Sep-2014 06:01, Jakob Ovrum пишет:
On Friday, 12 September 2014 at 16:33:50 UTC, Dmitry Olshansky wrote:
Agreed.
I think that the total amount of live (not garbage) exceptions on heap
is small for any typical application. Thus just special casing the
hell out of exception allocation in the
On Friday, 12 September 2014 at 21:31:45 UTC, Johannes Pfau wrote:
Am Fri, 12 Sep 2014 12:59:22 +
schrieb Marc Schütz schue...@gmx.net:
On Friday, 12 September 2014 at 03:37:10 UTC, Jakob Ovrum
wrote:
1b) Exceptions constructed at compile-time which are then
later referenced at
On Saturday, 13 September 2014 at 08:19:10 UTC, Marc Schütz wrote:
On Friday, 12 September 2014 at 21:31:45 UTC, Johannes Pfau
wrote:
Am Fri, 12 Sep 2014 12:59:22 +
schrieb Marc Schütz schue...@gmx.net:
Related: Last time I checked the runtime caches unwinding or
stack trace information in
allocated exception. This would make the exceptions
themselves still @nogc, but the GC would have a hook to
(potentially) collect them. For those that don't want that, then
they can make calls to the cleanup at deterministic times.
This, combined with the fact that we used an (unshared) allocator
On 9/12/14, Jakob Ovrum via Digitalmars-d digitalmars-d@puremagic.com wrote:
the chaining mechanism will
construct a self-referencing list that results in an infinite
loop when the chain is walked
Can we amend the spec to say self-referencing is ok? Then we could
make the default exception
On Friday, 12 September 2014 at 03:37:10 UTC, Jakob Ovrum wrote:
I can think of a couple of ways to go:
1) The most widely discussed path is to allocate exception
instances statically, either in global memory or TLS.
Currently, this has a few serious problems:
Another problem with this is
On Friday, 12 September 2014 at 03:37:10 UTC, Jakob Ovrum wrote:
1b) Exceptions constructed at compile-time which are then
later referenced at runtime (as in the above snippet) must be
immutable (the compiler enforces this), as this feature only
supports allocation in global memory, not in
12-Sep-2014 15:03, monarch_dodra пишет:
I like the option of having exception allocators that can later be
explicitly called in a release all exceptions style, or plugged into
the GC, to be cleaned up automatically like any other GC allocated
exception. This would make the exceptions themselves
Am Fri, 12 Sep 2014 12:59:22 +
schrieb Marc Schütz schue...@gmx.net:
On Friday, 12 September 2014 at 03:37:10 UTC, Jakob Ovrum wrote:
1b) Exceptions constructed at compile-time which are then
later referenced at runtime (as in the above snippet) must be
immutable (the compiler
Am Fri, 12 Sep 2014 12:47:44 +
schrieb Vladimir Panteleev vladi...@thecybershadow.net:
On Friday, 12 September 2014 at 03:37:10 UTC, Jakob Ovrum wrote:
I can think of a couple of ways to go:
1) The most widely discussed path is to allocate exception
instances statically, either in
On Friday, 12 September 2014 at 21:36:31 UTC, Johannes Pfau wrote:
I suggest looking at the C++ implementation. There's the
throw-by-value
catch-by-reference idiom. C++ must store/copy this exception
somewhere,
maybe they have a clever solution.
But then we can't have exception stack traces.
the exceptions
themselves still @nogc, but the GC would have a hook to
(potentially) collect them. For those that don't want that,
then they can make calls to the cleanup at deterministic times.
We can't change existing instances of `throw` to use such a
manually managed heap without silently causing user
On Friday, 12 September 2014 at 11:38:18 UTC, Andrej Mitrovic via
Digitalmars-d wrote:
On 9/12/14, Jakob Ovrum via Digitalmars-d
digitalmars-d@puremagic.com wrote:
the chaining mechanism will
construct a self-referencing list that results in an infinite
loop when the chain is walked
Can we
On Friday, 12 September 2014 at 12:47:46 UTC, Vladimir Panteleev
wrote:
On Friday, 12 September 2014 at 03:37:10 UTC, Jakob Ovrum wrote:
I can think of a couple of ways to go:
1) The most widely discussed path is to allocate exception
instances statically, either in global memory or TLS.
On Friday, 12 September 2014 at 16:33:50 UTC, Dmitry Olshansky
wrote:
Agreed.
I think that the total amount of live (not garbage) exceptions
on heap is small for any typical application. Thus just special
casing the hell out of exception allocation in the GC (and
compiler) is IMO perfectly
On Friday, 12 September 2014 at 21:36:31 UTC, Johannes Pfau wrote:
I think if we could avoid dynamic allocations for most
exceptions
completely that'd be better. IIRC some people said that
exceptions are
mainly slow because of memory allocation. So if we could avoid
that,
there are more
There is one massive blocker for `@nogc` adoption in D library
code: allocation of exception objects. The GC heap is an ideal
location for exception objects, but `@nogc` has to stick to its
promise, so an alternative method of memory management is
desirable if we want the standard library to
20 matches
Mail list logo
