On Wed, May 28, 2008 at 11:09 AM, Dave Parker <[EMAIL PROTECTED]> wrote: >> > If catch(set x to y+z.) < 0.1 then go to tinyanswer. >> >> So what does this do exactly if the set throws an error? > > I think the catch should catch the error thrown by set, compare it to > 0.1, the comparison will not return true because the error is not less > than 0.1, and so the go-to to tinyanswer will not be taken. >
The semantics you're describing aren't clear here. I suppose that's sort of reasonable, given that you haven't implemented it yet, but let's think about it for a second. You say the catch construct should catch the error thrown by set, but 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. So then I considered that maybe you meant the error in the sense of some determination of floating point roundoff error, but that can't be it, since you've claimed recently a big win over Python with FT in that it has no roundoff error. So what, exactly, is the error you could even be catching in that? Assuming the answer is "You're right, there's no actual error that could generated by that assignment," there are two options: the compiler optimizes it away, or you throw a compile-time error. The latter makes more sense, as someone trying to catch an exception where one can't possibly exist probably indicates a misunderstanding of what's going on. > ... That's why C had to > resort to the confusing "=" vs "==" notation -- to disambiguate the > two cases. The "catch" keyword unambiguously alerts the reader that > the parenthesis contain a statement (or a whole list of statements). > 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. 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, but it doesn't give any indication to what could come out and ideally, only one thing (or its descendants in a type hierarchy) can come out. (I suppose this can be solved by overloading your comparison operators.) Beyond that, I think you would want a good mechanism for comparing ranges of values if you want to make exceptions/errors real-valued. >> For that matter, is there any way to distinguish between different errors >> and only catch particular ones? > > I think the catch function should catch all of the errors (and the non- > error result if no error occured), so I think distinguishing the error > would have to come after. Maybe something like: > > Set result to catch(read x from "input.txt".). > If result = dividebyzeroerror then ... else throw result. > > I'm open to alternate suggestions, though. > -- http://mail.python.org/mailman/listinfo/python-list
