On 06/02/2017 01:26 PM, Steven Schveighoffer wrote:
If only that is what happened, I would not have started this thread!
In any case, the way forward is clear -- create containers that don't
throw Error, and make them easy to use.
I think I will actually publish them, because it's a very useful thing
to have. You can validate your input all you want, but if you have a
program bug, or there is something you didn't consider, then the entire
server isn't crashed because of it. I *like* the bounds checking, I
don't have to translate back to the input what it will mean for every
array access in the function -- the simple check is enough.
Still good to have it auto-restart, which I will also do. But having
some sort of feedback to the client, and an attempt to continue on with
other unrelated requests is preferable.
-Steve
Hi,
I think that most people agree that an out-of-bounds access is a bug
that needs to be fixed, this shouldn't be an acceptable way of running
the program.
The question here seems to be what to do *in the meanwhile*, and here is
the problem. I can understand the position that from a theoretical point
of view the process is already unsafe at this point, and that the best
option is to stop (and restart if needed).
But, in the real world if I've got a (web)server that has proper
isolation, I'd much rather have a server that sends back a 500 [error
message] for the buggy page and keeps working otherwise, than one that
is killed and has to be restarted every time a buggy page is asked.
Think that it can be a multithreaded server, and that other ongoing (and
safe!) tasks might be affected, and that safe restart, even when
available, often has a performance hit.
I agree that one (perhaps even the proper) way to get this is through
process isolation, but this doesn't mean that the language shouldn't
allow it if needed and explicitly required. There are ways for the
programmer to explicitly disable most other security features
(__gshared, casting away shared and immutable, @trusted code, etc.) so
why not this one?
Perhaps an intermediate solution would be to offer a compiler switch
that allows Errors to be safely caught (that is, they behave as
exceptions). As far as I understand from reading this thread, that's
already the case in debug builds, so it cannot be that bad practice, but
it would be nice to have a mode that it's otherwise "release", only with
this feature turned on.
Even better would be to turn on this behaviour on a per-function basis
(say @throwErrors). Although perhaps that'd be promoting this behaviour
a bit too much...
Anyway, just 2ยข from a half-newbie (okay, still full-newbie :) )
