On 2013-10-09 17:36:01 +0000, Johannes Pfau <[email protected]> said:
Am Wed, 9 Oct 2013 13:13:51 -0400
schrieb Michel Fortin <[email protected]>:
On 2013-10-09 16:51:03 +0000, Manu <[email protected]> said:
On 10 October 2013 01:40, Johannes Pfau <[email protected]> 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
[email protected]
http://michelf.ca
