How big of a problem would that actually be? Regards, Alex
On Thu, Mar 15, 2012 at 12:19 AM, Brad Roberts <[email protected]> wrote: > Actually, the interaction of errors with @nothrow is a very specific part > of the problem. @nothrow allows the compiler to NOT setup the > infrastructure to catch throwables at all. This allows for some useful > optimizations. So, saying that Errors can be caught means that they have > to be dis-allowed in @nothrow functions too. > > On Wed, 14 Mar 2012, Jesse Phillips wrote: > >> It seems to me that everyone has an expectation that finalizers are >> attempted. And is my personal expectation. While Errors are not >> Exceptions they are being thrown via the Exception system and so it >> make sense to make a proper attempt at cleanup. >> >> I will submit one piece of evidence toward this. OutOfMemoryError is >> valid to recover from and is only an error so that @nothrow and other >> restrictions do not apply to it, as it is always a potential problem. >> However not doing cleanup could prevent proper recover of OutOfMemory, >> and yes cleanup itself could fail, oh well. >> >> Many times the Error comes from code which doesn't exist in release. >> This means it is safe to cleanup and do other operations, but you >> can't rely on it for program flow. This is where I like having the >> current state. It allows my environment to be returned to the original >> state (remove temporary files) without having to create an Error >> handling tree too. >> >> On Mon, Mar 12, 2012 at 5:35 PM, Walter Bright <[email protected]> >> wrote: >> > >> > On 3/12/2012 2:39 PM, Sean Kelly wrote: >> >> >> >> On Mar 12, 2012, at 2:30 PM, Walter Bright wrote: >> >>> >> >>> On 3/12/2012 12:34 PM, Sean Kelly wrote: >> >>>> >> >>>> I'm on the fence about whether attempting cleanup when an Error is >> >>>> thrown is desired behavior. If there is no cleanup, why allow Errors >> >>>> to be >> >>>> caught at all? We may as well simply call abort() at the point they're >> >>>> thrown. >> >>>> >> >>> So that an informative message can be printed, the backup engaged, >> >>> attempt to shut down gracefully, log the failure details to a file, etc. >> >> >> >> ? none of which may work if scope(exit) calls weren't run when the stack >> >> was unwound, since acquired mutexes would still be locked, etc. I'd feel >> >> a >> >> lot less safe with having effectively done a longjmp across code that >> >> normally assumes finalization than with whatever the cause of the >> >> assertion >> >> did in the first place. >> >> >> > >> > It's understood it may not work. >> _______________________________________________ >> 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 _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
