RE: help raise hell
On Mon, 11 Aug 2003, Joseph F. Ryan wrote: How are you currently throwing/catching exceptions? I think it might be much more difficult to create a model that traps exceptions, rather than setting up code that just figures out how to handle an exception when it occurs. Both JVM-PIR and P6C use continuations to handle exceptions, albeit in different ways. Anyways, since I can't read python, could you explain what you are using now? (-: Sure. This: try: raise 'hell' except: pass Becomes this: 1: .sub __main__ 2: new_pad 0 3: setline 1 # (set_lineno:85) 4: .local Sub handler0 # (visitTryExcept:723) 5: newsub handler0, .Exception_Handler, catch0 # (visitTryExcept:724) 6: set_eh handler0 # (visitTryExcept:726) 7: setline 3 # (set_lineno:85) 8: .local object ex0 # (visitRaise:701) 9: .local object msg0# (visitRaise:702) 10: ex0 = new Exception # (visitRaise:703) 11: msg0 = new PerlString # (expressConstant:164) 12: msg0 = 'hell' # (expressConstant:165) 13: ex0['_message'] = msg0# (visitRaise:705) 14: throw ex0 # (visitRaise:706) 15: goto endtry0 # (visitTryExcept:728) 16: catch0: 17: noop # (visitPass:688) 18: endtry0: 19: end # (compile:817) 20: .end 21: .include 'pirate.imc' If you throw an uncaught exception in python, python has a default handler that prints out the traceback (call stack) shows the error message, and then terminates (or optionally invokes the python prompt). So... I'm saying all generated python programs should have one of these giant try-except blocks around them, and that's what I mean by trapping the exception. In the above example, if I did raise hell instead of raise 'hell', python would throw a NameError that I could trap just like any other exception: try: raise hell except NameError: print There is no hell. except: print Something else went wrong. (my code only gives you one except: block so far, but real python lets you have as many as you like for different types of exceptions) Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: help raise hell
On Mon, Aug 11, 2003 at 03:30:44AM -0400 it came to pass that Michal Wallace wrote: because a find_lex failure isn't an exception. Or am I missing something? Currently find_lex does *not* throw an exception. Inside scratchpad_get(and friends) an internal exception is thrown which just terminates parrot. I have been discussing thiw with Leo on the list (look in the archives for subjects matching find_lex. Plans are to have find_lex throw an exception. My favourite is to have a control flag that lets find_lex throw an exception *or* return NULL upon failure. ++Jos.nl -- La vida no es la que uno vivió, sino la que recuerda y cómo la recuerda para contarla... ~ Gabriel García Márquez
RE: help raise hell
-Original Message- Date: Mon 08/11/03 3:30 AM From: Michal Wallace [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: Subject: help raise hell Here is how I usually trigger a generic exception in python: raise hell Traceback (most recent call last): File stdin, line 1, in ? NameError: name 'hell' is not defined Unfortunately, I can't seem to trap that in parrot, because a find_lex failure isn't an exception. Or am I missing something? CAN trap this though: raise 'hell' So it's not a showstopper, but still... Is this easily fixable? I miss my idiom... :) How are you currently throwing/catching exceptions? I think it might be much more difficult to create a model that traps exceptions, rather than setting up code that just figures out how to handle an exception when it occurs. Both JVM-PIR and P6C use continuations to handle exceptions, albeit in different ways. Anyways, since I can't read python, could you explain what you are using now? (-: - Joe -- This message was sent using 3wmail. Your fast free POP3 mail client at www.3wmail.com
help raise hell
Here is how I usually trigger a generic exception in python: raise hell Traceback (most recent call last): File stdin, line 1, in ? NameError: name 'hell' is not defined Unfortunately, I can't seem to trap that in parrot, because a find_lex failure isn't an exception. Or am I missing something? CAN trap this though: raise 'hell' So it's not a showstopper, but still... Is this easily fixable? I miss my idiom... :) Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
