On 2015-02-16 at 22:12, Jonathan Marler wrote:
On Monday, 16 February 2015 at 19:12:45 UTC, FG wrote:
Range violation is an Error, but never mind that. The real question is: given
all the work related to @nogc, wouldn't it be better for such common Errors to
be preallocated and only have file and line updated when they are thrown?
@nogc already, because they simply cast typeid(OutOfMemoryError).init or
typeid(InvalidMemoryOperationError).init:
extern (C) void onOutOfMemoryError(void* pretend_sideffect = null) @trusted
pure nothrow @nogc
extern (C) void onInvalidMemoryOperationError(void* pretend_sideffect = null)
@trusted pure nothrow @nogc
Could be made @nogc with one object of each kind preallocated:
extern (C) void onAssertError( string file = __FILE__, size_t line = __LINE__ )
nothrow
extern (C) void onRangeError( string file = __FILE__, size_t line = __LINE__ )
@safe pure nothrow
extern (C) void onSwitchError( string file = __FILE__, size_t line = __LINE__ )
@safe pure nothrow
This could be a good idea for some types of exceptions. I believe OutOfMemory
is already pre-allocated (it has to be since you can't allocate it once you are
out of memory). The problem with your suggestion is that if you allow the
exception to be updated with the line number/filename(it isn't immutable), then
you have to store it in TLS memory. That may be an acceptable tradeoff, but
you have to take that into consideration. Also if you have a chain of
exceptions you wouldn't be able to include the same exception more then once in
the chain.
The problem D has with exceptions and GC memory is complex and will have
different optimal solutions in different cases. In some cases, it would be
better for D to support non-GC heap allocated exceptions. Maybe these types of
exceptions could be derived from another class so the user code will know that
the memory needs to be freed. There are also other ideas but my point is we
should make a plan about what solutions we think would be good to implement and
determine which ones we want to tackle first.
Yes, they would be in TLS. I know exceptions in general are a complex problem,
therefore I limited the comment only to errors, because forbidding the use of
`aa[key]` in @nogc seemed odd (although I do think that `aa.get(key, default)`
and `key in aa` are superior to `aa[key]`). I have seen a few examples of
Exception chaining, but not Error chaining, and since Error trumps Exception,
whatever else was raised was of less importance to me, so I didn't give much
thought to that.
And as for the extra non-GC exception class, maybe, I'm not sure, but it should
nevertheless be a subclass of Exception to allow for a simple catch-all.
