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

On Mar 12, 2012, at 2:34 PM, Don Clugston wrote:
> 
> Well  I've never heard that before, and I wrote the code on Windows to
> make sure that they do get executed.
> It's not an accident that it works.

The same is true for Posix.  And there are even established rules (created by Don) about how exception chaining should work for Exceptions vs. Errors.  We could change it to work as apparently documented, but it would be a change to existing behavior.

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Monday, March 12, 2012 22:34:25 Don Clugston wrote:
> Well I've never heard that before, and I wrote the code on Windows to
> make sure that they do get executed.
> It's not an accident that it works.

I believe that Walter (and maybe Andrei?) has said it before - which is where
I heard it from - but I haven't been able to find any posts confirming that, and
none of the documentation says it as far as I can tell - which is why I
started this thread to verify it. So, it really doesn't seem unreasonable for
people to expect that all Throwables function the same with regards to scope
statements, destructors, and finally blocks. If we really want them to act
differently, we need to say so clearly. The intended design is definitely _not_
being gotten across clearly at this point.

There are advantages to having Errors skip cleanup, but there are definite disadvantages too, and particularly given that they _don't_ currently skip cleanup, I'm increasingly inclined to say that we should just guarantee that they're guaranteed to do the cleanup just like normal Exceptions are.

- Jonathan M Davis
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

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

On Mar 12, 2012, at 5:35 PM, Walter Bright <walter@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.

So what's the reason to not call finalizers?
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Mar 12, 2012, at 10:29 PM, Sean Kelly <sean@invisibleduck.org> wrote:

> The handler is deprecated because DMD doesn't generate a valid call stack for _d_assert (which calls onAssertError) so it's impossible to return from the assert handler without throwing. This rendered the assert handler largely useless and after a few years of no one using it I decided to deprecate it. I'd be happy to keep the assert handler if people actually want it though, or if DMD changes its codegen. Personally, I'd like to be able to assert without throwing in some testing situations, and overriding a handler seems like an appropriate way to do this.

I would use it if it worked. Currently I'm catching AssertError which doesn't feel completley safe after the discussions here and in the newsgroup.

On Tue, Mar 13, 2012 at 21:31, Jacob Carlborg <doob@me.com> wrote:
>
> I would use it if it worked. Currently I'm catching AssertError which doesn't feel completley safe after the discussions here and in the newsgroup.
>

D's implementation of inherited contracts currently relies on catching errors, so you're safe at least until that is fixed.

---------------


import std.random, std.stdio;

class A
{
    void fun()
    in
    {
        scope(failure)
            writeln("Uh-oh!  Access violation?!?!");
        while(true)
        {
            uint v = uniform(0, uint.max);
            *(cast(uint*)v) = v;
        }
    }
    body
    {
    }
}

class B : A
{
    override void fun()
    in
    {
    }
    body
    {
        writeln("Nah, it was probably nothing");
    }
}

void main()
{
    auto b = new B();
    b.fun();
}

--------------
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

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

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

How big of a problem would that actually be?

Regards,
Alex

On Thu, Mar 15, 2012 at 12:19 AM, Brad Roberts <braddr@puremagic.com> 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 <walter@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@puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals