On 30.05.2012 19:05, Steven Schveighoffer wrote:
On Wed, 30 May 2012 05:32:00 -0400, Don Clugston <d...@nospam.com> wrote:

On 30/05/12 10:40, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 10:26:36 deadalnix wrote:
The fact that error don't trigger scope and everything is nonsensial.

If an Error is truly unrecoverable (as they're generally supposed to
be), then
what does it matter? Something fatal occured in your program, so it
terminates. Because it's an Error, you can get a stack trace and report
something before the program actually terminates, but continuing
execution
after an Error is considered to be truly _bad_ idea, so in general,
why does
it matter whether scope statements, finally blocks, or destructors get
executed? It's only rarer cases where you're trying to do something like
create a unit test framework on top of assert that you would need to
catch an
Error, and that's questionable enough as it is. In normal program
execution,
an error is fatal, so cleanup is irrelevant and even potentially
dangerous,
because your program is already in an invalid state.

That's true for things like segfaults, but in the case of an
AssertError, there's no reason to believe that cleanup would cause any
damage.

There's also no reason to assume that orderly cleanup *doesn't* cause
any damage. In fact, it's not reasonable to assume *anything*.

Which is the point. If you want to recover from an error, you have to do
it manually. It should be doable, but the default handling should not
need to be defined (i.e. implementations should be free to do whatever
they want).

But there is no reasonable *default* for handling an error that the
runtime can assume.


I'd say that calling scope, destructors etc. on Error being thrown is the most _useful_ thing in all cases. If you realy-realy afraid of memory corruption killing sensitive data, taking control of OS and so on - you just catch Errors early on inside such sensitive functions. And call C's abort(). And that's it.

Let's make common and hard case default and automatic plz.

--
Dmitry Olshansky

Reply via email to