iPhone vs Android

[Jonathan M Davis via Digitalmars-d]

On Tuesday, September 13, 2016 16:13:05 H. S. Teoh via Digitalmars-d wrote:
> On Tue, Sep 13, 2016 at 03:19:54PM -0700, Jonathan M Davis via Digitalmars-d
> wrote: [...]
>
> > But none of the code that's marked @nogc can throw an exception unless
> > you're either dealing with pre-allocated exceptions (in which case,
> > they're less informative),
>
> I don't see why pre-allocated exceptions would be less informative. You
> can always modify the exception object before throwing it, after all.
> In fact, I've always wondered about the feasibility of a @nogc exception
> handling system where the exception is emplaced onto a fixed static
> buffer, so that no allocation (except at the start of the program) is
> actually necessary. Of course, chained exceptions throw(!) a monkey
> wrench into the works, but assuming we forego chained exceptions,
> wouldn't this work around the problem of being unable to allocate
> exceptions in @nogc code? (Albeit with its own limitations, obviously.
> But it would be better than being unable to use exceptions at all in
> @nogc code.)

As Walter points out, it's a problem if exceptions are ever saved (which
some code does need to do). The fact that you lose chaining as you pointed
out is also a problem. You also have problems because the file, line, and
message of the exception either aren't going to be specific to when that
exception is thrown, or you have to set them all before throwing, in which
case you have issues with if/when the exception is reused. And regardless of
all of that, the fact that string is used for the message throws a wrench in
things for @nogc, since that's going to require GC allocation unless you
cast something to string, and then you have serious problems if you need to
mutate it later, since you'll end up violating the compiler guarantees for
immutable.

>
> [...]
>
> > So, I really think that we need to find a way to make it so that
> > exceptions aren't GC allocated normally anymore - or at least have a
> > way to reasonably and easily not be GC allocated - but the problem is
> > @nogc, not the actual memory management or its cost.
>
> [...]
>
> There's nothing about the 'throw' keyword that requires GC allocation.
> It's just that `throw new Exception(...)` has become a standard
> incantation. The exception object itself can, for example, be emplaced
> onto a static buffer as I propose above.

Yes, there are ways to work around allocating an exception with new right
before throwing it, but that's really how things are designed to work, and
there are serious problems with any attempt to work around it. At minimum,
it makes throwing exceptions to be a lot more of a pain then it is when
using the GC (meaning that plenty of folks will just happily use the GC when
they wouldn't need it aside from the exception, which then renders their
code unable to be @nogc), and really, that's enough to be a serious problem.
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.

At this point, I'd say that exceptions can be used in @nogc in rare
circumstances where you're very careful about what you're doing, but in the
general case, it's really not an option. Realistically, if we want folks to
be using exceptions in @nogc in general, I think that it needs to be about
as simple as throw new Exception(message); is, and we're not even close to
that. Without that, we're likely to end up with a divide between code that
uses the GC and code that uses exceptions.

- Jonathan M Davis