The "no gc" crowd

[Michel Fortin]

On 2013-10-09 17:36:01 +0000, Johannes Pfau <nospam at example.com> said:

> Am Wed, 9 Oct 2013 13:13:51 -0400
> schrieb Michel Fortin <michel.fortin at michelf.ca>:
> 
>> On 2013-10-09 16:51:03 +0000, Manu <turkeyman at gmail.com> said:
>> 
>>> On 10 October 2013 01:40, Johannes Pfau <nospam at example.com> wrote:
>>> 
>>>> But if someone really wants to strip the GC _completely_ there's a
>>>> huge issue with memory management of Exceptions.
>>> 
>>> Exceptions have a pretty well defined lifetime... can't they be
>>> manually cleaned up by the exception handler after the catching
>>> scope exits?
>> 
>> Exceptions don't need a well-defined lifetime for things to work.
> 
> What I meant was using exceptions without the GC requires huge changes
> (like switching all exceptions to use reference counting) or at least
> using the same type of allocation for all exceptions. If you have
> 'malloced' and GC owned exceptions it can be hard to know if an
> Exception needs to be freed:
> 
> try
> {
>     codeWithMallocException();
>     codeWithGCException();
> }
> catch(Exception e)
> {
>     //Am I supposed to free this exception now?
> }

Sorry. I think I got mixed up in different branches of this huge 
discussion thread. This branch is about having a separate attribute to 
split ref-counted objects from GC objects, but having the two coexist. 
Other branches are about replacing the GC with a ref-counted GC, but 
that's not what we're talking about here.

You are perfectly right that you can't mix GC exceptions with 
ref-counted exceptions. And if ref-counted exceptions can't derive from 
the garbage collected Exception class, then it becomes awfully 
complicated (probably impossible) to have exception without having the 
GC cleaning them up.

I was wrong, that's an issue. It's no different than the general issue 
that you need to have a separate root class however. You simply need a 
separate root exception class too, one that you'd have to catch 
explicitly and that catch (Exception e) would not catch. That's not 
very practical.

-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca