> right now!), writing exception safe code is not just a matter of using RAII
> and dtors to clean up. Please see <http://herbsutter.com/gotw/_102/> for
> example.
Yes; noone is suggesting there's an automatic conversion; it'd be a
lot of careful work. This particular classic EH hazard should be
particularly amenable to a local static analysis.
> Also, see things like exceptions escaping from destructors and so on.
It seems like a convention involving noexcept and supported with extra
static checks (analogous to the "can this function GC?" static
analyses we have now) would be effective here too.
> And most importantly, logic errors caused by the state of the program
> being left in an inconsistent form after an exception is risen and handled
> properly as far as the language is concerned.
In general, the exception exits would be at the same points as the
'return false'. Of course there will be weird cases like:
bool ok = foo();
doSomething();
if (!ok)
return false;
but these are precisely the maintenance hazards we've been refactoring
away from. If we were to undertake a migration to EH, an intermediate
step could be to have the static analysis require that all error
return values return immediately on failure before doing anything
else. I'm sure there are other interesting corner cases and I'd be
curious to hear about any examples that weren't things weren't already
maintenance hazards today and amenable to static checks.
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
