iPhone vs Android

[Jonathan M Davis via Digitalmars-d]

On Wednesday, September 14, 2016 07:43:29 H. S. Teoh via Digitalmars-d wrote:
> > But the fact that the workarounds either require that you don't have
> > unique, independent exceptions or that you know that you need to
> > manually free the exception after catching it is a serious problem.
> > And that's without even taking the exception chaining into account.
>
> [...]
>
> Using a preinitialized region allocator, we no longer have such
> limitations.

And how would you deal with the fact that the catching code is generally
going to assume that it has a GC-allocated exception? It's not going to do
anything to free the exception when it's done with it, and it could keep the
exception around for an indeterminate amount of time. So, having the code
that manages the allocator later assume that the exception was freed would
be unsafe. I don't see how it's going to work in the general case to have a
an exception class which is anything other than GC allocated - not as long
as it can't be wrapped in a struct that knows how to deal with freeing its
memory when it's done. Because you either end up with an exception that gets
leaked, because the catching code doesn't know that it needs to do something
to free it, or you run the risk of it being freed prematurely when the code
that manages its memory assumes that the code that caught it didn't keep it.

Obviously, if you're talking about a smaller application that isn't sharing
code with anything, you have more control over what's going on, and you can
afford to make assumptions about what is happening with exceptions and are
thus more likely to get away with stuff that won't work in the general case.
But libraries definitely have to care, and larger applications are going to
tend to have to care, because if there's enough code, it simply isn't going
to work to assume that it all behaves in a way that differs from how
exceptions normally work. Someone else is going to come onto the project and
write perfectly normal D code that then has nasty bugs when an exception
gets thrown, because other code within that large application was doing
something with exceptions that didn't work with normal D code (like
allocating them with a different allocator that won't allow you to hold onto
the exception for an arbitrary amount of time without it being mutated out
from under you or even outright freed).

- Jonathan M Davis