On 2016-01-04 4:48 PM, Luke Wagner wrote:
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.
Agreed. :-)
> This particular classic EH hazard should be
particularly amenable to a local static analysis.
Yes. So I have actually been thinking about this a bit. It's true that
for this example you can perform a simple static check, but other cases
can't really be usefully checked statically. Here are two examples:
1. In order to detect whether an exception can escape a destructor, you
need to disallow calling non-noexcept functions, which is problematic
since many destructors for RAII types for example need to call into
non-noexcept library functions. In this case you need checks that will
incur some runtime overhead in order to enforce exception safety.
2. In order to detect whether a resource leaks if something throws, you
need to know what conditions are considered as a "leak". It's trivial
to know that for object allocations, but not for logical resources (for
example an OS handle that you received from a C API, which is an integer
as far as the compiler is concerned.
Some of these can be solved at runtime if the overhead is acceptable.
But in general creating tools for all of them is time consuming, and I'm
not surprised if a few cases are undetectable.
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.
For this kind of analysis, we need two things. One is the callgraph,
similar to the current checker. The other is knowing whether a function
actually throws, or whether it's only declared as non-noexcept because
for example it calls a non-noexcept API that actually never throws.
But yeah, there may be approaches that I’m missing.
Cheers,
Ehsan
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
