www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - I can has nogc and throw Exceptions?

reply "Jonathan Marler" <johnnymarler gmail.com> writes:
This question comes from wanting to be able to throw an exception 
in code that is  nogc.

I don't know if it's possible but I'd like to be able to throw an 
exception without allocating memory for the garbage collector?  
You can do it in C++ so I think you should be able to in D.  One 
idea I had was to allocate the memory for the Exception 
beforehand and create the Exception class with the pre-allocated 
memory.  I came up with the following code:

T construct(T,A...)(void* buffer, A args)
{
   return (cast(T)buffer).__ctor(args);
}

Now to test it:

void main()
{
   ubyte[ __traits(classInstanceSize, Exception)] exceptionBuffer;
   throw construct!(Exception)(exceptionBuffer.ptr, "My Exception 
Allocated on the STACK!");
}

I got an assertion error. I'm not sure why, but when I print out 
the contents of the buffer of my stack exception it differs from 
an exception created for the garbage collector with "new".  It 
looks like it has some accounting information embedded in the 
class instance. I figured as much but I didn't think the code 
that performs the "throw" would be dependent on this.

Also, this doesn't look like a very safe option because the 
initial values for the class members don't get set using this 
"construct" template.

If anyone has any other ideas or a way to fix mine let me know, 
thanks.
Feb 13 2015
next sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Friday, 13 February 2015 at 19:03:10 UTC, Jonathan Marler 
wrote:
 This question comes from wanting to be able to throw an 
 exception in code that is  nogc.

 I don't know if it's possible but I'd like to be able to throw 
 an exception without allocating memory for the garbage 
 collector?  You can do it in C++ so I think you should be able 
 to in D.  One idea I had was to allocate the memory for the 
 Exception beforehand and create the Exception class with the 
 pre-allocated memory.  I came up with the following code:

 T construct(T,A...)(void* buffer, A args)
 {
   return (cast(T)buffer).__ctor(args);
 }

 Now to test it:

 void main()
 {
   ubyte[ __traits(classInstanceSize, Exception)] 
 exceptionBuffer;
   throw construct!(Exception)(exceptionBuffer.ptr, "My 
 Exception Allocated on the STACK!");
 }

 I got an assertion error. I'm not sure why, but when I print 
 out the contents of the buffer of my stack exception it differs 
 from an exception created for the garbage collector with "new".
  It looks like it has some accounting information embedded in 
 the class instance. I figured as much but I didn't think the 
 code that performs the "throw" would be dependent on this.

 Also, this doesn't look like a very safe option because the 
 initial values for the class members don't get set using this 
 "construct" template.

 If anyone has any other ideas or a way to fix mine let me know, 
 thanks.
1. Throw preallocated exceptions is the way to go 2. Allocating them on the stackframe that will cease to exist by throwing is a bad idea 3. use emplace To construct a type in preallocated memory
Feb 13 2015
parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 13 February 2015 at 19:09:43 UTC, Tobias Pankrath 
wrote:
 1. Throw preallocated exceptions is the way to go
... and because noone has yet shown an explicit example: void myThrowingNogcFunc() nogc { static const exc = new Exception("something went wrong"); throw exc; } As long as you don't need to pass a runtime argument to the constructor, there's no need for emplace acrobatics.
Feb 13 2015
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 2/13/15 4:08 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net>" 
wrote:
 On Friday, 13 February 2015 at 19:09:43 UTC, Tobias Pankrath wrote:
 1. Throw preallocated exceptions is the way to go
.... and because noone has yet shown an explicit example: void myThrowingNogcFunc() nogc { static const exc = new Exception("something went wrong"); throw exc; } As long as you don't need to pass a runtime argument to the constructor, there's no need for emplace acrobatics.
shared static const, unless you want one per thread (doesn't make a whole lot of sense, since it's const). -Steve
Feb 13 2015
prev sibling parent reply Adam Sansier <Adam.Sansier gmail.com> writes:
On Friday, 13 February 2015 at 21:08:58 UTC, Marc Sch├╝tz wrote:
 On Friday, 13 February 2015 at 19:09:43 UTC, Tobias Pankrath 
 wrote:
 1. Throw preallocated exceptions is the way to go
... and because noone has yet shown an explicit example: void myThrowingNogcFunc() nogc { static const exc = new Exception("something went wrong"); throw exc; } As long as you don't need to pass a runtime argument to the constructor, there's no need for emplace acrobatics.
Why not? If the argument is static? (A string literal, surely this shouldn't be a problem and usually what is used?) void myThrowingNogcFunc(string s)() nogc { static const exc = new Exception(s); throw exc; } ? I too am looking for nogc exceptions. How about simply setting aside a 100kb of memory as a pool for exceptions. Seems like a lot but still under 640kb, hell, even 1MB would still be tiny. After all, it's not like exceptions are common or happen in complex ways. Does anyone have a proper solution to this problem? I'd like nogc exception handling with run-time generated args.
Jul 12 2016
parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
On Wednesday, 13 July 2016 at 00:57:38 UTC, Adam Sansier wrote:
 How about simply setting aside a 100kb of memory as a pool for 
 exceptions. Seems like a lot but still under 640kb, hell, even 
 1MB would still be tiny.

 After all, it's not like exceptions are common or happen in 
 complex ways.

 Does anyone have a proper solution to this problem? I'd like 
 nogc exception handling with run-time generated args.
You shall use a static per-thread Region allocator[1] backed by Mallocator[2]. Then you just make[3] exceptions inside it and throw them. So you can allocate and chain exceptions until you end the memory established on creation. Whenever you don't need the exception chain anymore (i.e.: you catched them and program is back in "normal" mode, you just reset the region allocator, so you have all of your memory again, for the next exception chain). [1] https://dlang.org/phobos/std_experimental_allocator_building_blocks_region.html [2] https://dlang.org/phobos/std_experimental_allocator_mallocator.html [3] https://dlang.org/phobos/std_experimental_allocator.html
Jul 13 2016
parent reply Adam Sansier <Adam.Sansier gmail.com> writes:
On Wednesday, 13 July 2016 at 11:39:11 UTC, Lodovico Giaretta 
wrote:
 On Wednesday, 13 July 2016 at 00:57:38 UTC, Adam Sansier wrote:
 [...]
You shall use a static per-thread Region allocator[1] backed by Mallocator[2]. Then you just make[3] exceptions inside it and throw them. So you can allocate and chain exceptions until you end the memory established on creation. Whenever you don't need the exception chain anymore (i.e.: you catched them and program is back in "normal" mode, you just reset the region allocator, so you have all of your memory again, for the next exception chain). [1] https://dlang.org/phobos/std_experimental_allocator_building_blocks_region.html [2] https://dlang.org/phobos/std_experimental_allocator_mallocator.html [3] https://dlang.org/phobos/std_experimental_allocator.html
Am I going to have to do all this myself or is it already done for me somewhere?
Jul 13 2016
next sibling parent Eugene Wissner <belka caraus.de> writes:
I'm writing currently a library, that is 100%  nogc but not 
nothrow, and I slowly begin to believe that I should publish it 
already, though it isn't ready yet. At least as example.
std.experimental.allocator doesn't work nicely with  nogc. for 
example dispose calls destroy, that isn't  nogc.
I wrote a primitive native allocator for linux and some help 
functions, that replaces phobos functions till they aren't 
 nogc-ready. For example for throwing the exceptions:

void raise(T : Throwable, A...)(Allocator allocator, auto ref A 
args)
{
	auto e = make!T(allocator, args);
	throw e;
}


and you can throw then with raise!Exception("bla-bla")


On Wednesday, 13 July 2016 at 16:13:21 UTC, Adam Sansier wrote:
 On Wednesday, 13 July 2016 at 11:39:11 UTC, Lodovico Giaretta 
 wrote:
 On Wednesday, 13 July 2016 at 00:57:38 UTC, Adam Sansier wrote:
 [...]
You shall use a static per-thread Region allocator[1] backed by Mallocator[2]. Then you just make[3] exceptions inside it and throw them. So you can allocate and chain exceptions until you end the memory established on creation. Whenever you don't need the exception chain anymore (i.e.: you catched them and program is back in "normal" mode, you just reset the region allocator, so you have all of your memory again, for the next exception chain). [1] https://dlang.org/phobos/std_experimental_allocator_building_blocks_region.html [2] https://dlang.org/phobos/std_experimental_allocator_mallocator.html [3] https://dlang.org/phobos/std_experimental_allocator.html
Am I going to have to do all this myself or is it already done for me somewhere?
Jul 13 2016
prev sibling parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
On Wednesday, 13 July 2016 at 16:13:21 UTC, Adam Sansier wrote:
 On Wednesday, 13 July 2016 at 11:39:11 UTC, Lodovico Giaretta 
 wrote:
 On Wednesday, 13 July 2016 at 00:57:38 UTC, Adam Sansier wrote:
 [...]
You shall use a static per-thread Region allocator[1] backed by Mallocator[2]. Then you just make[3] exceptions inside it and throw them. So you can allocate and chain exceptions until you end the memory established on creation. Whenever you don't need the exception chain anymore (i.e.: you catched them and program is back in "normal" mode, you just reset the region allocator, so you have all of your memory again, for the next exception chain). [1] https://dlang.org/phobos/std_experimental_allocator_building_blocks_region.html [2] https://dlang.org/phobos/std_experimental_allocator_mallocator.html [3] https://dlang.org/phobos/std_experimental_allocator.html
Am I going to have to do all this myself or is it already done for me somewhere?
It's actually quite easy. Here's the code (untested): ================================================================ import std.experimental.allocator.building_blocks.region; import std.experimental.allocator.mallocator; import std.experimental.allocator; Region(shared(Mallocator)) exception_allocator; enum EXCEPTION_MEM_SIZE = 256*1024; static this() { exception_allocator = typeof(exception_allocator)(EXCEPTION_MEM_SIZE); } ================================================================ And here is an usage example (untested, too): ================================================================ void throwingFunction() { // try to do something, but fail throw exception_allocator.make!Exception("my wonderful error message"); } void throwingThrowingFunction() { try { // try to call function, which fails throwingFunction; } catch (Exception exc) { // try to recover from failure, but generate other exception (just to show chaining) throw exception_allocator.make!Exception("I love exception chaining"); } } void main() { try { // try to call function, which fails throwingThrowingFunction; } catch (Exception exc) { // recover from failure, then deallocate the exceptions no longer needed exception_allocator.deallocateAll; } } ================================================================
Jul 13 2016
parent reply Adam Sansier <Adam.Sansier gmail.com> writes:
On Wednesday, 13 July 2016 at 16:28:23 UTC, Lodovico Giaretta 
wrote:
 On Wednesday, 13 July 2016 at 16:13:21 UTC, Adam Sansier wrote:
 On Wednesday, 13 July 2016 at 11:39:11 UTC, Lodovico Giaretta 
 wrote:
 On Wednesday, 13 July 2016 at 00:57:38 UTC, Adam Sansier 
 wrote:
 [...]
You shall use a static per-thread Region allocator[1] backed by Mallocator[2]. Then you just make[3] exceptions inside it and throw them. So you can allocate and chain exceptions until you end the memory established on creation. Whenever you don't need the exception chain anymore (i.e.: you catched them and program is back in "normal" mode, you just reset the region allocator, so you have all of your memory again, for the next exception chain). [1] https://dlang.org/phobos/std_experimental_allocator_building_blocks_region.html [2] https://dlang.org/phobos/std_experimental_allocator_mallocator.html [3] https://dlang.org/phobos/std_experimental_allocator.html
Am I going to have to do all this myself or is it already done for me somewhere?
It's actually quite easy. Here's the code (untested): ================================================================ import std.experimental.allocator.building_blocks.region; import std.experimental.allocator.mallocator; import std.experimental.allocator; Region(shared(Mallocator)) exception_allocator; enum EXCEPTION_MEM_SIZE = 256*1024; static this() { exception_allocator = typeof(exception_allocator)(EXCEPTION_MEM_SIZE); } ================================================================ And here is an usage example (untested, too): ================================================================ void throwingFunction() { // try to do something, but fail throw exception_allocator.make!Exception("my wonderful error message"); } void throwingThrowingFunction() { try { // try to call function, which fails throwingFunction; } catch (Exception exc) { // try to recover from failure, but generate other exception (just to show chaining) throw exception_allocator.make!Exception("I love exception chaining"); } } void main() { try { // try to call function, which fails throwingThrowingFunction; } catch (Exception exc) { // recover from failure, then deallocate the exceptions no longer needed exception_allocator.deallocateAll; } } ================================================================
Doesn't work. identifier expected on shared. What's the difference of simply using malloc to allocate the memory and creating the exceptions their? Seems like a long and winded way go about it or is there some benefit to using the experimental allocators?
Jul 13 2016
parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
On Wednesday, 13 July 2016 at 20:44:52 UTC, Adam Sansier wrote:
 On Wednesday, 13 July 2016 at 16:28:23 UTC, Lodovico Giaretta 
 wrote:
 It's actually quite easy. Here's the code (untested):

 ================================================================

 import std.experimental.allocator.building_blocks.region;
 import std.experimental.allocator.mallocator;
 import std.experimental.allocator;


 Region(shared(Mallocator)) exception_allocator;
 enum EXCEPTION_MEM_SIZE = 256*1024;
 static this()
 {
     exception_allocator = 
 typeof(exception_allocator)(EXCEPTION_MEM_SIZE);
 }

 ================================================================

 And here is an usage example (untested, too):

 ================================================================

 void throwingFunction()
 {
     // try to do something, but fail
     throw exception_allocator.make!Exception("my wonderful 
 error message");
 }

 void throwingThrowingFunction()
 {
     try
     {
         // try to call function, which fails
         throwingFunction;
     }
     catch (Exception exc)
     {
         // try to recover from failure, but generate other 
 exception (just to show chaining)
         throw exception_allocator.make!Exception("I love 
 exception chaining");
     }
 }

 void main()
 {
     try
     {
         // try to call function, which fails
         throwingThrowingFunction;
     }
     catch (Exception exc)
     {
         // recover from failure, then deallocate the 
 exceptions no longer needed
         exception_allocator.deallocateAll;
     }
 }
 ================================================================
Doesn't work. identifier expected on shared. What's the difference of simply using malloc to allocate the memory and creating the exceptions their? Seems like a long and winded way go about it or is there some benefit to using the experimental allocators?
`Region(shared(Mallocator))` shall be `Region!(shared Mallocator)` (again, I'm just looking at the code, didn't test it). The advantages over a simple malloc are: 1) You can change between GC allocation, malloc, mmap and other allocators by changing a single line, instead of changing every throw; 2) you can use very fast allocators, based on your needs; this example uses the Region allocator, which is way faster than a call to malloc; 3) the Region allocator has the added value of working even if there's no more memory available (because it preallocated it). In general, the allocators library provides facilities that may seem overkill for simple tasks (and in fact they are), but prove very flexible and useful for advanced uses, or to write generic highly customizable code. Of course, being experimental, this library has still some issues...
Jul 13 2016
parent reply Adam Sansier <Adam.Sansier gmail.com> writes:
On Wednesday, 13 July 2016 at 20:57:49 UTC, Lodovico Giaretta 
wrote:
 On Wednesday, 13 July 2016 at 20:44:52 UTC, Adam Sansier wrote:
 On Wednesday, 13 July 2016 at 16:28:23 UTC, Lodovico Giaretta 
 wrote:
 It's actually quite easy. Here's the code (untested):

 ================================================================

 import std.experimental.allocator.building_blocks.region;
 import std.experimental.allocator.mallocator;
 import std.experimental.allocator;


 Region(shared(Mallocator)) exception_allocator;
 enum EXCEPTION_MEM_SIZE = 256*1024;
 static this()
 {
     exception_allocator = 
 typeof(exception_allocator)(EXCEPTION_MEM_SIZE);
 }

 ================================================================

 And here is an usage example (untested, too):

 ================================================================

 void throwingFunction()
 {
     // try to do something, but fail
     throw exception_allocator.make!Exception("my wonderful 
 error message");
 }

 void throwingThrowingFunction()
 {
     try
     {
         // try to call function, which fails
         throwingFunction;
     }
     catch (Exception exc)
     {
         // try to recover from failure, but generate other 
 exception (just to show chaining)
         throw exception_allocator.make!Exception("I love 
 exception chaining");
     }
 }

 void main()
 {
     try
     {
         // try to call function, which fails
         throwingThrowingFunction;
     }
     catch (Exception exc)
     {
         // recover from failure, then deallocate the 
 exceptions no longer needed
         exception_allocator.deallocateAll;
     }
 }
 ================================================================
Doesn't work. identifier expected on shared. What's the difference of simply using malloc to allocate the memory and creating the exceptions their? Seems like a long and winded way go about it or is there some benefit to using the experimental allocators?
`Region(shared(Mallocator))` shall be `Region!(shared Mallocator)` (again, I'm just looking at the code, didn't test it). The advantages over a simple malloc are: 1) You can change between GC allocation, malloc, mmap and other allocators by changing a single line, instead of changing every throw;
Ok, I like!
 2) you can use very fast allocators, based on your needs; this 
 example uses the Region allocator, which is way faster than a 
 call to malloc;
I like too! But I'll have to assume you are right since I have no proof.
 3) the Region allocator has the added value of working even if 
 there's no more memory available (because it preallocated it).
Well, one could do this with malloc because one can pre-allocate it too. I figure this is why you stated 2 though because it is pre-allocated? So, really only point 1 stands, but that is probably not even valid since one can wrap the allocator in a template. This is probably exactly what is being done.. So, ultimately no real benefit except the implementation details have been removed. That's not a bad thing as long as it works ;)
 In general, the allocators library provides facilities that may 
 seem overkill for simple tasks (and in fact they are), but 
 prove very flexible and useful for advanced uses, or to write 
 generic highly customizable code.
 Of course, being experimental, this library has still some 
 issues...
Well, I will try out the code and see. You've provided an example and if it works then it should be good enough in my case. If it doesn't limit what I need to do then I'm happy ;) How is phobo's going to deal with such things when it is trying to get off the GC? It surely has to throw exceptions. Similar method or something entirely different? Thanks.
Jul 13 2016
parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
On Wednesday, 13 July 2016 at 21:12:29 UTC, Adam Sansier wrote:
 The advantages over a simple malloc are:
 1) You can change between GC allocation, malloc, mmap and 
 other allocators by changing a single line, instead of 
 changing every throw;
Ok, I like!
 2) you can use very fast allocators, based on your needs; this 
 example uses the Region allocator, which is way faster than a 
 call to malloc;
I like too! But I'll have to assume you are right since I have no proof.
 3) the Region allocator has the added value of working even if 
 there's no more memory available (because it preallocated it).
Well, one could do this with malloc because one can pre-allocate it too. I figure this is why you stated 2 though because it is pre-allocated? So, really only point 1 stands, but that is probably not even valid since one can wrap the allocator in a template. This is probably exactly what is being done.. So, ultimately no real benefit except the implementation details have been removed. That's not a bad thing as long as it works ;)
 In general, the allocators library provides facilities that 
 may seem overkill for simple tasks (and in fact they are), but 
 prove very flexible and useful for advanced uses, or to write 
 generic highly customizable code.
 Of course, being experimental, this library has still some 
 issues...
Well, I will try out the code and see. You've provided an example and if it works then it should be good enough in my case. If it doesn't limit what I need to do then I'm happy ;) How is phobo's going to deal with such things when it is trying to get off the GC? It surely has to throw exceptions. Similar method or something entirely different? Thanks.
At the end, all memory comes from one of these: GC heap, malloc, mmap, sbrk. All other allocators build on top of these (or on top of user supplied buffers, which come from these as well). What those "wrapper" allocators do is managing the given memory, either using different allocations strategies for different allocation sizes, or keeping lists of free blocks instead of returning them using "free", or other things (have a look at the docs). So at the end they do what you would manually do in C/C++ to "personalize" the allocations, with the aim of reducing waste and/or being faster. They are also arbitrarily composable on top of each other. I don't know how Phobos will handle exceptions. Maybe use reference counting (coming soon in D, maybe)? Maybe algorithms that already have to allocate will switch from using the GC to using a user-supplied custom allocator, and will use it for exceptions too. Currently I'm working on a replacement for std.xml and I'm making every component take a template parameter to specify the allocator. Initially the allocators look like a real mess, but after a couple of days playing with them, you start understanding the mechanics and at the end you really enjoy them. Changing a single parameters allows to switch between safe gc code and nogc code in the unittests, without changing the implementation.
Jul 13 2016
parent reply Adam Sansier <Adam.Sansier gmail.com> writes:
On Wednesday, 13 July 2016 at 21:27:16 UTC, Lodovico Giaretta 
wrote:
 On Wednesday, 13 July 2016 at 21:12:29 UTC, Adam Sansier wrote:
 [...]
Ok, I like!
 [...]
I like too! But I'll have to assume you are right since I have no proof.
 [...]
Well, one could do this with malloc because one can pre-allocate it too. I figure this is why you stated 2 though because it is pre-allocated? So, really only point 1 stands, but that is probably not even valid since one can wrap the allocator in a template. This is probably exactly what is being done.. So, ultimately no real benefit except the implementation details have been removed. That's not a bad thing as long as it works ;)
 [...]
Well, I will try out the code and see. You've provided an example and if it works then it should be good enough in my case. If it doesn't limit what I need to do then I'm happy ;) How is phobo's going to deal with such things when it is trying to get off the GC? It surely has to throw exceptions. Similar method or something entirely different? Thanks.
At the end, all memory comes from one of these: GC heap, malloc, mmap, sbrk. All other allocators build on top of these (or on top of user supplied buffers, which come from these as well). What those "wrapper" allocators do is managing the given memory, either using different allocations strategies for different allocation sizes, or keeping lists of free blocks instead of returning them using "free", or other things (have a look at the docs). So at the end they do what you would manually do in C/C++ to "personalize" the allocations, with the aim of reducing waste and/or being faster. They are also arbitrarily composable on top of each other. I don't know how Phobos will handle exceptions. Maybe use reference counting (coming soon in D, maybe)? Maybe algorithms that already have to allocate will switch from using the GC to using a user-supplied custom allocator, and will use it for exceptions too. Currently I'm working on a replacement for std.xml and I'm making every component take a template parameter to specify the allocator. Initially the allocators look like a real mess, but after a couple of days playing with them, you start understanding the mechanics and at the end you really enjoy them. Changing a single parameters allows to switch between safe gc code and nogc code in the unittests, without changing the implementation.
Ok. Is there a way to bundle allocations so that one free will work? For example, your exception handling looks good but I need to supply custom messges. If I use sformat I have to create the array for the buffer to create the message in. This means I would have to free both the exception and the string. It would be nice to be able to do this in one go. Also, could one create a struct or class for the exception so that it is automatically free'ed at the end of a catch block, if caught? Probably not without language help? Sometimes it's nice to include runtime info in an error message such as an OS error code.
Jul 13 2016
parent Lodovico Giaretta <lodovico giaretart.net> writes:
On Wednesday, 13 July 2016 at 22:42:36 UTC, Adam Sansier wrote:
 On Wednesday, 13 July 2016 at 21:27:16 UTC, Lodovico Giaretta 
 wrote:
 At the end, all memory comes from one of these: GC heap, 
 malloc, mmap, sbrk. All other allocators build on top of these 
 (or on top of user supplied buffers, which come from these as 
 well). What those "wrapper" allocators do is managing the 
 given memory, either using different allocations strategies 
 for different allocation sizes, or keeping lists of free 
 blocks instead of returning them using "free", or other things 
 (have a look at the docs). So at the end they do what you 
 would manually do in C/C++ to "personalize" the allocations, 
 with the aim of reducing waste and/or being faster. They are 
 also arbitrarily composable on top of each other.

 I don't know how Phobos will handle exceptions. Maybe use 
 reference counting (coming soon in D, maybe)? Maybe algorithms 
 that already have to allocate will switch from using the GC to 
 using a user-supplied custom allocator, and will use it for 
 exceptions too.

 Currently I'm working on a replacement for std.xml and I'm 
 making every component take a template parameter to specify 
 the allocator. Initially the allocators look like a real mess, 
 but after a couple of days playing with them, you start 
 understanding the mechanics and at the end you really enjoy 
 them. Changing a single parameters allows to switch between 
  safe gc code and  nogc code in the unittests, without 
 changing the implementation.
Ok. Is there a way to bundle allocations so that one free will work? For example, your exception handling looks good but I need to supply custom messges. If I use sformat I have to create the array for the buffer to create the message in. This means I would have to free both the exception and the string. It would be nice to be able to do this in one go. Sometimes it's nice to include runtime info in an error message such as an OS error code.
As you probably saw, sformat still has some problems with nogc, because it internally uses std.uft.encode, which may throw a GC-allocated exception, but this can be solved. Not all allocators keep track of the memory ranges they allocated (e.g.: Mallocator). The ones that do (like Region) usually provide a deallocateAll method. So the idea is that you allocate all data needed by your exception (string buffers or whatever) and the exception itself with one of these allocators, and at the end of a catch you deallocateAll.
 Also, could one create a struct or class for the exception so 
 that it is automatically free'ed at the end of a catch block, 
 if caught? Probably not without language help?
I don't think it's feasible without language support for reference counted classes (which may be added sooner or later, as it has been asked and proposals have been made, and would be very useful). Also note that you don't want RAII or scope(exit) in this case but scope(success), as the exception shall not be deallocated if another one is raised in the catch block, because in D the second exception does not "overwrite" the first, but is chained to it, so that an outer catch can see both of them.
Jul 14 2016
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 13 February 2015 at 19:03:10 UTC, Jonathan Marler 
wrote:
 T construct(T,A...)(void* buffer, A args)
 {
   return (cast(T)buffer).__ctor(args);
 }
This is wrong, you need to initialize the memory first to the proper values for the class, gotten via typeid(T).init. std.conv.emplace does this correctly, either use it or look at its source to see how to do it.
   ubyte[ __traits(classInstanceSize, Exception)] 
 exceptionBuffer;
When the stack unwinds, this will be invalidated... I don't think stack allocated exceptions are ever a good idea. I don't think malloc exceptions are a good idea either, the catcher would need to know to free it. You might preallocate a pool of GC'd exceptions though, then throw the next one in the list instead of making a new one each time.
Feb 13 2015
parent "Jonathan Marler" <johnnymarler gmail.com> writes:
On Friday, 13 February 2015 at 19:10:00 UTC, Adam D. Ruppe wrote:
 On Friday, 13 February 2015 at 19:03:10 UTC, Jonathan Marler 
 wrote:
 T construct(T,A...)(void* buffer, A args)
 {
  return (cast(T)buffer).__ctor(args);
 }
This is wrong, you need to initialize the memory first to the proper values for the class, gotten via typeid(T).init. std.conv.emplace does this correctly, either use it or look at its source to see how to do it.
That's what I was looking for! Thanks.
  ubyte[ __traits(classInstanceSize, Exception)] 
 exceptionBuffer;
When the stack unwinds, this will be invalidated... I don't think stack allocated exceptions are ever a good idea. I don't think malloc exceptions are a good idea either, the catcher would need to know to free it. You might preallocate a pool of GC'd exceptions though, then throw the next one in the list instead of making a new one each time.
Yes I am aware of these things. Stack allocated exception are dangerous if you let them get thrown above the function they were allocated in. But this is easy to prevent by simply making sure you catch the exception in the function you allocate it in. And yes malloc'd exceptions would be odd since the convention is to allocate them on the GC heap so no one would think they had to free them. Also you could use a global...but I'm also aware of the caveats of this, between excessive TLS memory and the dangers of using shared or __gshare memory. A pool of pre-allocated exceptions is an idea I was throwing around...but with this new emplace function it opens up my options. Thanks.
Feb 13 2015
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 2/13/15 2:03 PM, Jonathan Marler wrote:
 This question comes from wanting to be able to throw an exception in
 code that is  nogc.

 I don't know if it's possible but I'd like to be able to throw an
 exception without allocating memory for the garbage collector? You can
 do it in C++ so I think you should be able to in D.  One idea I had was
 to allocate the memory for the Exception beforehand and create the
 Exception class with the pre-allocated memory.  I came up with the
 following code:

 T construct(T,A...)(void* buffer, A args)
 {
    return (cast(T)buffer).__ctor(args);
 }

 Now to test it:

 void main()
 {
    ubyte[ __traits(classInstanceSize, Exception)] exceptionBuffer;
    throw construct!(Exception)(exceptionBuffer.ptr, "My Exception
 Allocated on the STACK!");
 }

 I got an assertion error. I'm not sure why, but when I print out the
 contents of the buffer of my stack exception it differs from an
 exception created for the garbage collector with "new".  It looks like
 it has some accounting information embedded in the class instance. I
 figured as much but I didn't think the code that performs the "throw"
 would be dependent on this.

 Also, this doesn't look like a very safe option because the initial
 values for the class members don't get set using this "construct" template.

 If anyone has any other ideas or a way to fix mine let me know, thanks.
You need to actually allocate the memory on the heap. Your data lives on the stack frame of main, which goes away as soon as main exits, and your exception is caught outside main. -Steve
Feb 13 2015
parent "Jonathan Marler" <johnnymarler gmail.com> writes:
On Friday, 13 February 2015 at 19:13:02 UTC, Steven Schveighoffer 
wrote:
 You need to actually allocate the memory on the heap. Your data 
 lives on the stack frame of main, which goes away as soon as 
 main exits, and your exception is caught outside main.

 -Steve
Yes I am aware of this. That doesn't mean you have to allocate on the GC heap. You can 1. Make sure the exception is caught before the function that allocated the memory for it on the stack (not the safest thing to do but works) 2. Allocate the memory on the NON-GC heap 3. Allocate the memory to a global
Feb 13 2015