Actually I'm mostly interested in what...

Post #119,854 by ChrisR 10/2/03 2:22:40 PM Reply	Actually I'm mostly interested in what... ...Neel is tossing around as the alternatives for his implementation, so I'm just engaging in a little idle speculation. :-) As far as I can tell exceptions involve two things: (1). a set of code to run when an exception occurs; and (2). a continuation point to jump to once that code is completed. I gathered from your assesment that you think these features have been reduced to a glorified goto construct (reversing the order i just gave). My point, if there was one, was that instead of being a label to which one branches to, the code to be executed can also be thought of as anonymous function which gets fired when an exception event us triggered. No comment was given on the effect in terms of continuation. Anyhow, other than establishing whether an event is handled or whether it simply throws the exception up the continuation stack, the checked exception handling in Java doesn't give any other clues to the compiler (for static checking purposes). Might be valuable information, but it provides no information beyond the propagation.
Post #119,880 by ben_tilly 10/2/03 6:02:06 PM Reply	What my thinking on this is... In the original Go To Considered Harmful paper, a number of still valid uses for goto were listed. Exception handling was one of those. AFAIK, exception systems were created to provide for an "exceptional program flow" mechanism which was still structured, attempting to eliminate a problem that goto was still used for. So it isn't that exceptions come down to a glorified goto, it is that they are good enough at subverting the structured flow of control that they can share some of the problems that goto has. See [link\|http://c2.com/cgi/wiki?AvoidExceptionsWheneverPossible\|http://c2.com/cgi/wi...sWheneverPossible] for an entry point into a similar discussion. Cheers, Ben "good ideas and bad code build communities, the other three combinations do not" - [link\|http://archives.real-time.com/pipermail/cocoon-devel/2000-October/003023.html\|Stefano Mazzocchi]
Post #119,921 by neelk 10/2/03 10:34:48 PM Reply	Re: Actually I'm mostly interested in what... What I'd like is for exception handlers to be lexically scoped rather than dynamically scoped. For example, consider the pseudocode: \nfun make_foo() {\n try {\n lambda(){ raise Error; }\n } catch (Error) {\n print("Error caught in make_foo!");\n }\n}\n\nfun main() {\n try\n let foo = make_foo();\n foo();\n catch (Error) {\n print("Error caught in main!");\n }\n}\n In a conventional exception system, running main() would result in foo() throwing an error that would be caught in main, and the message that main prints would be "Error caught in main!". This is dynamic scoping -- the exception handler chosen is the nearest enclosing handler live on the call stack. I'd like to try a lexically scoped exception system. In this version, the exception thrown in foo() would be caught by the lexically-enclosing exception handler -- that is, the one in make_foo(). So the printed message would be "Error caught in make_foo!" As it happens, a lexical discipline offers more powerful control flow than a dynamic one (you can write call/cc with it!!), but it is also easier to analyze in a modular way. But this isn't the whole story. To make such a system really useful to the programmer, you still need a type language that can express differing sets of exceptions concisely and precisely, and that's a hard problem: the two needs are at cross-purposes. But the lack of such is what makes Java's checked exceptions mostly useless.
Post #119,974 by ChrisR 10/3/03 10:52:18 AM Reply	Why not include the exception processing in the lambda? Not sure I understand why the exception processing is not bundled as part of the anonymous function: \nfun make_foo() {\n lambda(){ \n try { \n raise Error; \n } catch (Error) {\n print("Error caught in make_foo!");\n }\n }\n}\n Would the catch not then be lexically scoped within the lambda function? I guess I don't understand what you are trying to. In the current languages, the exception within make_foo would only be trapped if the error were in the creation of the lambda function - not in the invocation. Also, I gather you still think the continuation point should be based on the point of invocation - not the point of defintion. So do you think the next statement executed after the try-catch in the main block? \nfun main() {\n try\n let foo = make_foo();\n foo();\n catch (Error) {\n print("Error caught in main!");\n }\n print("here's where i end up when all is said and done?");\n}\n
Post #120,007 by neelk 10/3/03 3:21:13 PM Reply	Re: Why not include the exception processing in the lambda? The exception isn't part of the lambda, since I was trying to come up with the shortest example that illustrated the issue I was talking about. :) Also, I gather you still think the continuation point should be based on the point of invocation - not the point of defintion. So do you think the next statement executed after the try-catch in the main block? \nfun main() {\n try\n let foo = make_foo();\n foo();\n catch (Error) {\n print("Error caught in main!");\n }\n print("here's where i end up when all is said and done?");\n} I'm not sure what you mean by "continuation point should be based on the point of invocation", but I do want execution to continue normally after the exception is handled (that's kind of the point of an exception, after all!). So your example should print \nError caught in make_foo!\nhere's where i end up when all is said and done?\n

Welcome to IWETHEY!