auto classes and finalizers

[Sean Kelly]

Mike Capp wrote:
> In article <e2378s$gpn$1 at digitaldaemon.com>, Sean Kelly says...
>> the next release [of Ares] will include a 
>> hookable callback in the standard library similar to onAssertError. 
>> This will allow the user to decide upon which behavior is most 
>> appropriate, and to do so on a per-class basis as I am planning to pass 
>> either the original class pointer or simply a ClassInfo object.
> 
> To clarify: if the decision is per-class (which I agree it should be), is there
> any benefit to catching this error at runtime rather than compile time? Or is it
> just that it's easier to try out this way?

I'm not entirely sure it would be possible to catch every instance of 
this at compile-time.  That aside, I very much want to avoid anything 
requiring compiler changes unless Walter is the one to implement them, 
and really to avoid any fundamental changes in application behavior 
without Walter's approval.  This is one reason I've chosen to add this 
feature via a hookable callback that defaults to existing behavior (ie. 
to ignore the problem and continue).  The other being that I'm not 
convinced such errors always warrant termination, particularly for 
release builds.

To clarify, I've added two callbacks and a user-callable function to my 
local build:

     void setCollectHandler( collectHandlerType h );
     extern (C) void onCollectResource( ClassInfo info );

onCollectResource is called whenever the GC collects an object that has 
a dtor and if not user-supplied handler is provided then the call is a 
no-op.  I may yet replace the ClassInfo object with an Object reference, 
but haven't decided whether doing so offers much over the current version.

     extern (C) void onFinalizeError( ClassInfo c, Exception e );

onFinalizeError is called whenever an Exception is thrown from an object 
dtor and will effectively terminate the application with a message. 
This is accomplished by wrapping the passed exception in a new 
system-level exception object and re-throwing.  Things get a bit weird 
if e is an OutOfMemoryException, but that's a possibility I'm ignoring 
for now.


Sean