[LRUG] [Chat] IronRuby

[James Adam]

On 7/24/07, Pratik Naik <pratik at thinkwares.com> wrote:
> But imagine something like http://pastie.caboo.se/81719

I'd argue that even your namespaced exceptions are going to be
problematic in the long run.

Essentially, what you're doing when you use exceptions (*any*
exceptions) is creating a kind of "GOTO" statement. It's
super-convenient for when you know that something has happened, and
there's just no point in continuing with the "normal" program flow
(i.e. disk is full, network is not responding, or so on), but
"super-convenient" doesn't always equate to good programming style.

When you throw an exception, you're literally casting the thread of
execution somewhere else, and (as far as the current method is
concerned) you don't care (or necessarily know) where that thread is
going to start executing in your code. It's this kind of
jumping-around that makes the program difficult to read later, because
it's not clear where to look when you see that something is being
thrown ("up the stack" is the answer, but that only exists when the
code is running).

By having models throwing exceptions, and controllers catch them,
you're effectively having to maintain a set of GOTO and LABEL
statements spread throughout your code. These things are useful -
that's why they exist! - but they are also dangerous if you use them a
lot.

Incidentally, another way to solve the problem in the current context
might be to encapsulate the various states of your object and push all
that information back down into the model
(http://pastie.caboo.se/81755), and use a normal if-then control
structure, rather than rescuing. This way you're not bleeding so much
implementation information up from the model into the controller, and
you can interrogate the current state of your model without having the
execution thread jumping around out of your immediate control.

-- 
* J *
  ~