[dmd-internals] Throwing Errors

[Brad Roberts]

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 <walter at digitalmars.com> 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
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>