[dmd-internals] Throwing Errors

[Alex]

How big of a problem would that actually be?

Regards,
Alex

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