Python and Flaming Thunder

[Dave Parker]

On May 28, 12:48 pm, "Dan Upton" <up... at virginia.edu> wrote:
> there's no reason "set" itself
> should throw any sort of error in the sense of an exception--in a
> statement like "Set x to SomeFunctionThatCanBlowUp()", the semantics
> should clearly be that the error comes from the function.  In a simple
> addition statement, that makes no sense.

For example:

  Set z to catch(somefunctionthatmightblowup(...)).
  If catch(set x to y+z.) < 0.1 then go to tinyanswer.

Or something like that.  Or if you change the + to a / and z is 0.0,
for example, then it could cause a divide-by-zero exception.  There is
no guarantee that the + won't cause an exception, given that there is
no guarantee that y and z are both numeric.

> However, I think overloading your catch error types to include objects
> (or integral values, I guess, your example below isn't clear) along
> with real values (ignoring the bit above about whether floating-point
> assignment could throw an error) makes things confusing.

Catch doesn't return just error types or numbers, it can return any
object returned by the statements that are being caught; catch doesn't
care what type they are.  For example:

  Writeline catch(set x to "hello world".).

will write "hello world".

> It's nice
> that "catch(stuff)" indicates that there's one or more statements
> inside, but so does indentation in Python, bracketing in C/C++,
> Begin/End in <insert language here>, and so forth, ...

Except that in those languages, I don't think that the indentation,
bracketing, Begin/End, etc, can be used in expressions.  Catch can.
For example, catch will return the final value of z:

If catch(Set x to y+z. Set y to x+z.  Set z to 1/(x+y).) < 0.1 then go
to tinyanswer.

> Beyond that,
> I think you would want a good mechanism for comparing ranges of values
> if you want to make exceptions/errors real-valued.

I am thinking that exceptions/errors should have any kinds of values
the programmer wants to give them.  Some people prefer error numbers,
some prefer error messages, some prefer error identifiers, etc.  I am
thinking that the Error function should simply take a list of whatever
objects the user wants to throw, and throw them.  For example, if the
programmer wanted an error number and an error message for a
particular error:

  If x < 10 then throw error(10, "Please enter a number >= 10").

They could then do something like:

  Set result to catch(funtionthatcouldblowup(...)).
  If result is an error then if result(1) = 10 then writeline
result(2).

Thank you for your comments, they are helping me to clarify my own
thinking on error handling in general and on catch in particular.