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 <[email protected]> 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 > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-internals _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
