Throwing in Delete

(Sorry if it has already been mentioned, but the search feature is currently unavailable).

Throwing from the Delete method causes memory leaks. Actually I was expecting this as throwing in a destructor is a no no in C++. But I was hoping BlitzMax to be able to cope with it given the simpler memory model, and above all the fact that memory is reclaimed in a separate phase, when calling FlushMem.
Anyway, it doesn't appear so.
I'm also a bit surprised because when it was asked if BlitzMax was going to have destructors, skidracer mentioned the fact that allowing destructors would bring the potential problem of having an exception thrown during the garbage collection. Now we finally have destructors, so what's the official position regarding throwing in the Delete method?

Framework brl.blitz
Type MyType
	Method Delete()
		RuntimeError("Delete")
	End Method
End Type

Repeat
	Try
		FlushMem
		Local obj:MyType = New MyType
	Catch ex:TRuntimeException
	End Try
Forever

I still think handling this - without simply saying throwing in the Delete method is evil - is possible, but that's just a guess.

Hi,

I believe this should be made illegal.

While it may be possible to kludge it into the current mem system, it could severely limit our ability to implement different mem systems in future.

Is throwing cheese cake possible?

Ok thanks. A little note in the docs would be welcome :)

Well, hadn't even thought about it until now.

Of course, there's the question about what to do if an exception does get thrown inside delete - throwing an exception is probably not a good idea!

I say forget sweating this piddly little stuff and keep the mods coming :) I mean we don't even have a GUI.

Hi again.
I was wondering if you couldn't simply catch any exception thrown from Delete, and do nothing with it.
Would look perfect to me.

Simple but slow method (pseudo-code of an hypothetic internal GC loop):

Local obj:Object  = GetFirstObjectToFinalize()
While ptr <> Null
	Try ' internally, saves all the information needed to unwind the stack if an exception is thrown (takes time)
		obj.Delete()
	Catch ex:Exception
		' Do nothing, as if the Delete method had just exited
		' Note: this is what the .Net Platform GC does
	End Try
	obj = GetNextObjectToFinalize(obj)
Wend

The problem of this version is that we pay for the Try, so even if no exception is thrown we incur a performance hit.


Another solution, almost as simple and with no overhead as long as no exception is thrown:

Local obj:Object  = GetFirstObjectToFinalize()
Try
	While ptr <> Null
		obj.Delete()
		.AfterFinalization
		obj = GetNextObjectToFinalize(obj)
	Wend
Catch ex:Exception
	Goto AfterFinalization
End Try

That is, you simply put the try/catch out of the loop that iterates over the objects that have a Delete method.

I have been thinking about how it may possibly restrict your GC implementation options, but quite frankly I can't find.
Given that it seems very doable to do it with no performance hit, it may be worth a look.