On Thursday, 6 February 2014 at 21:48:13 UTC, Dicebot wrote:
On Thursday, 6 February 2014 at 19:54:27 UTC, Sean Kelly wrote:
Does this case even matter? Exceptions are not a normal
function of execution, and so should happen rarely to never.
And it's a time when I'd expect a delay anyway.
Imagine intentionally crafted broken utf as user input in
repeated requests. You don't have control over it.
Now if Phobos would have only thrown exceptions in really
_exceptional_ situations and handled broken input gracefully...
That's a tough one. Bad input typically shouldn't generate an
exception, but sometimes doing so is handy from a flow control
perspective (I know I know, exceptions aren't for flow control).
In the few instances where I use an exception for flow control
though (like core.demangle) I always use a static instance, so no
allocation occurs, and it's entirely internal to the routine.
I think it's fair to say that _an_API_ shouldn't allocate and
throw an exception to indicate an expected error condition. For
a parser, invalid input definitely applies. So then if the user
wants to throw an exception in that case, they can do so
themselves. Then the choice of allocation is left to the user,
not imposed on them. It's generally really easy to let the user
supply a delegate to execute on error too, so they don't even
necessarily have to check a return code.
