[dmd-internals] Throwing Errors

[Alex]

Let me just reply to this thread with a perspective that people seem
to not have regarded.

D is a systems language. That means it will be used to implement
things such as operating systems, drivers, server software, compilers,
debuggers, profilers, interpreters, JIT-backed virtual machines, and
so on.

By making OutOfMemoryError uncatchable, you're trying to shield
programmers from writing incorrect recovery code. I mean, excuse me,
but really? This is a *systems* language. Don't get me wrong. Safety
and expressiveness are the things I absolutely freaking love about D.
But this is not safety - it is a limitation. In C, I can recover from
lack of memory if I know what I'm doing; in D I can't (according to
this rule). This is a serious mistake IMO.

(On a somewhat related note, if OutOfMemoryError really is
uncatchable, why does the compiler not warn when you try to do so?)

But that's not all. Let's return to what I said before: Virtual
machines. Almost /all/ virtual machines use garbage collection; in
fact, most *enforce* it. In MCI, the D GC is provided as a GC
implementation that virtualized applications can use. In other words,
this means that the D GC is being used as *library*, not as a core
component of a language. Now, when applications running under MCI run
out of memory, they expect to see a null pointer returned, and to be
able to act upon that. This can't be accomplished if OutOfMemoryError
is made uncatchable. In other words, this forces me to remove the D GC
as an option over something as *absolutely ridiculously stupid* as
OutOfMemoryError being uncatchable. Really?!

What happens here is that a library component, something that is
supposedly optional to use (!), is being coupled tightly to language
semantics.

This needs to stop.

Regards,
Alex

On Sat, Mar 10, 2012 at 3:29 AM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> The issue of catching Errors came up in D.learn today, and I need some
> clarification. It has been my understanding that anything which is thrown which
> is not derived from Exception skips all destructors, scope statements, and
> finally blocks, meaning that it's generally unsafe to catch them, because your
> program is potentially in an invalid state. However, it was brought to my
> attention that the compiler does not currently follow this behavior - all 3 of
> those get run for Errors at present. So, the question is whether I'm just
> completely misunderstanding something or whether something has changed.
>
> Is it guaranteed that all thrown Throwables will result in all destructors,
> scope statements (exit and failure at least), and finally blocks that they pass
> being executed? Or is it only guaranteed for Exception and its derived types
> and just so happens to work for other exception types right now?
>
> I've been completely certain that such was _not_ guaranteed unless the
> exception type is Exception or derived from Exception, but I can't find any
> support for that searching the docs or newsgroup save for what I've said about
> it myself. So, I'd like official clarification on the matter.
>
> - Jonathan M Davs
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals