07-Feb-2014 20:49, Sean Kelly пишет:
On Friday, 7 February 2014 at 16:41:00 UTC, Dmitry Olshansky wrote:
Meh. If exceptions are such a liability we'd better make them (much)
faster.
It's not stack unwinding speed that's an issue here though, but rather
that for client-facing services, throwing an exception when an invalid
request is received gives malicious clients an opportunity to hurt
service performance by flooding it with invalid requests.
Why throwing a single exception is such a big problem? Surely even C's
long_jump wasn't that expensive? *Maybe* we shouldn't re-construct full
stack trace on every throw?
Improving the
exception code specifically doesn't help here because the real issue is
with GC collections.
Then the problem is that something so temporary as an exception is
allocated on the GC heap in the first place? Let's go for something more
sane and deprecate the current behavior, it's not like we are forever
stuck with it.
I'd say that the real fix is for such services to
simply not throw in this case. But the exception could always be
recycled as well (since in this case you know that throwing will abort
the transaction and so will always be immediately discarded).
Exceptions are convenient and they make life that much easier combined
with ctors/dtors and scoped lifetime. And then we say **ck it - for busy
services, just use good ol':
...
if (check42(...) == -1){ call_cleanup42(); return -1; }
...
And up the callstack we march. The moment code gets non-trivial there
come exceptions and RAII to save the day, I don't see how busy REST
services are unlike anything else.
I'm not
convinced that there's any need for a language change here to support
scoped exceptions. That seems a bit like killing the ant with a
steamroller.
Well I'm not convinced we should accept that exceptions are many times
slower then error codes (with checks on every function that may fail +
propagating up the stack).
--
Dmitry Olshansky
