13-Jan-2015 02:01, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
<ola.fosheim.grostad+dl...@gmail.com>" пишет:
On Monday, 12 January 2015 at 22:06:32 UTC, deadalnix wrote:
If you put aside performance concerns, exceptions for control flow
also tend to make many code path implicit and makes for very
unreadable/unmaintainable code.
But exceptions are control flow. There is no such thing as normalized
control flow, all state changes implies "control flow". Think in terms
of a state machine. You could just remove all variables and only have a
big state machine (assuming finite dimensions). Every single state
transition implies flow of control.
The control flow you see in the source code is just the programmer's
"rendition" of control flow. Exceptions is a mechanism for getting
cluttering resolution out of that rendition to make the code more
readable and maintainable. The goal is to retain the meat of the
computation and remove the noise.
Or to put it differently, there are many ways to write the same
function. Good use of exceptions removes the clutter and leaves the
things you care about visible. It's a mechanism, not a moral issue or a
religion.
So there is nothing wrong with throwing HTTPStatus(409) or
HTTPStatus(201), even though it returns state to the environment. If
that means the code is more maintainable and more likely to be correct,
then that is good use of the mechanism.
Actually I agree - exceptions are mechanism. Stressing _exceptional_ as
in "happening very rarely" is just a poor excuse to never optimize this
control-flow mechanism. I guess C/C++ inspired languages would never
have fast exceptions simply because of the mindset with the perception
of them being non-important or rare. Big adopters of C++ often avoided
exceptions entirely to not pollute binaries with EH-code only making
this issue worse.
In contrast, Java optimizes exceptions and re-writes many try/catch to
plain "gotos on error" control flows.
--
Dmitry Olshansky
