help raise hell

[Jos Visser]

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

[Michal Wallace]

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: mic...@sabren.com
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--------------------------------------

[Michal Wallace]

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)

[Joseph F. Ryan]

> -----Original Message-----
> Date: Mon 08/11/03 3:30 AM
> From: Michal Wallace <mic...@sabren.com>
> To: perl6-i...@perl.org
> 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