Re: Actually I'm mostly interested in what...

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!