On 9 Mrz., 13:50, Lie <[EMAIL PROTECTED]> wrote:
> On Mar 9, 4:31 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote:
>
>
>
> > On 9 Mrz., 09:30, Lie <[EMAIL PROTECTED]> wrote:
> > > On Mar 9, 12:05 pm, Kay Schluehr <[EMAIL PROTECTED]> wrote:
>
> > > > On 9 Mrz., 04:51, Lie <[EMAIL PROTECTED]> wrote:
>
> > > > > A more through implementation would start from the raiser inspecting
> > > > > the execution stack and finding whether there are any try block above
> > > > > it, if no try block exist it pass silently and if one exist it will
> > > > > check whether it have a matching except clause. This also circumvents
> > > > > a problem that simple implementation have, as described below.
>
> > > > This will not be easy in particular in the presence of inheritance and
> > > > dynamism. There is no way to statically decide whether an exception
> > > > BException has the type AException and will be caught by the except
> > > > clause in
>
> > > > try:
> > > > BLOCK
> > > > except AException, e:
> > > > print "SoftException %s caught"%e
> > > > A feasible solution was to invert the try...except statement and
> > > > creating a continuation.
>
> > > > catch AException, a:
> > > > print "SoftException A: %s"%a
> > > > catch BException , b:
> > > > print "SoftException B: %s"%b
> > > > ...
> > > > in:
> > > > BLOCK
>
> > > > Here each SoftException is raised initially when a catch clause is
> > > > entered and a continuation is created that returns to the catch block
> > > > of the raised SoftException if required. When a SoftException is
> > > > raised within BLOCK a lookup will be made and if a corresponding
> > > > SoftException was found that was raised by a catch-clause the current
> > > > control flow will be suspended and the continuation is called.
>
> > > I'd rather want to avoid any syntax changes, as I wished that Soft
> > > Exception can be added to the language silently[1] so that new
> > > programmers doesn't _need_ to know about it (although knowing it could
> > > change the way they write codes to be more structured and simple).
>
> > I just tried to save your proposal from being unimplementable. Maybe
> > you can comment on it?
>
> Perhaps I'm not the appropriate person to talk about whether unchanged
> syntax is feasible for such implementation since I basically have no
> idea about how Python's internals works. It's only that I think if
> current syntax could be used, we could just use it (except if there is
> a strong reason why it shouldn't be done).
You are an appropriate person to consider the workflow in a dynamic
language, no matter how the language is implemented internally.
Just start with function calls
maybe_raise(ZeroDivisionError)
The only requirement is that maybe_raise has to know when it shall
raise ZeroDivisionError. This depends on whether the exception is
caught. How do the program knows this in advance? There are no static
analysis techniques available.
When maybe_raise is entered the system must know that the exception is
handled in the future. You can't inspect the call stack for this
purpose because the call stack represents past events and
continuations ( and you can't rely on names ).
So you need something like this
do_softexception(ZeroDivisionError)
try:
TRY_BLOCK
except ZeroDivisionError:
EXCEPT_BLOCK
But this looks odd and the solution isn't DRY. So better one macro-
transforms a new statement into this form.
--
http://mail.python.org/mailman/listinfo/python-list
