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/
--------------------------------------


Reply via email to