[dmd-internals] Throwing Errors

Leandro Lucarella luca at llucax.com.ar
Thu Mar 15 14:13:26 PDT 2012


Walter Bright, el 14 de marzo a las 16:42 me escribiste:
> On 3/12/2012 7:07 PM, Sean Kelly wrote:
> >On 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.
> >So what's the reason to not call finalizers?
> 
> The program is corrupted at that point. The less code one attempts
> to run, the better.

Why? That's not always the case. And what could happen if you run
cleanup code in a program that you say is completely invalid? So why
would you care if the program gets more corrupted?

In the cases where the program is not completely in a corrupted state,
running the finalizers make totally sense, in the case where a program
is corrupted, it really doesn't matter, it's corrupted anyway. So why
sacrificing a case where catching errors doing cleanup is useful for
a case where it really doesn't matter?

This is specially bad if a memory allocation fail is an Error. It
basically forces you to check every allocation for a failure and
translate it yourself to some kind of Exception if you are being careful
to write some code that can survive to a memory allocation failure.

Why on earth do you want to make life miserable to people that have some
valid use case for this, just to avoid corrupting a little more
a program that's already corrupted.

Also adding special cases is ALWAYS confusing and error prone. Please,
please, please don't make errors a broken special case, unless you have
a very strong reason.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
La esperanza es una amiga que nos presta la ilusión.


More information about the dmd-internals mailing list