On May 28, 12:48 pm, "Dan Upton" <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
