[Tutor] running a script from IDLE

Scott Widney SWidney@ci.las-vegas.nv.us
Mon, 11 Mar 2002 18:51:05 -0800


> I think failure is best reported by raising an exception.
> 
> To my mind (based on limited FP experience) you want functions that
> return useful values - even if it is only a reference the the object
> that was passed into the function.  So long as the result of a 
> function makes sense as the argument for other functions, you have a
> function that can be used as a building block.  This is easy to see
> with math oriented processing.

Just to play Devil's Advocate a little longer....

I see what you mean with the math-oriented processing, especially because in
math, functions tend to be nested (sometimes greatly so). But on the object
side...

Let's say that I'm a bit of Controller code. My user (please no Tron cracks)
has just indicated that he wants his "icosa" rotated +90 degress on the
z-plane. I'm going to call icosa.rotate(z=90) or something similar. Before I
tell the View to refresh itself, I want to be sure that the Model has
changed. How can I be sure of that? As Kirby pointed out, most method calls
that change state return None.

Returning a pointer: whether we return a pointer to the
"your-old-state-data-has-been-destroyed" instance or to a new instance, I
still don't know if the transformation took place.

There's the "return a boolean flag" thing mentioned before, which would put
all of the error handling inside the method. But it doesn't reflect *what*
was wrong. It just reports failure or success.

So I need the descriptive power that exception handling provides. Here lies
the question: where do we put that try/except? Do we wrap it around the
method call and let the method raise an error that passes out of the call?
Or does the whole shebang go in the method? Could I see some appropriate
pseudocode?

Scott