Re: What c.l.py's opinions about Soft Exception?

On Mar 9, 4:31 pm, Kay Schluehr <kay.schlu...@xxxxxxx> wrote:
On 9 Mrz., 09:30, Lie <Lie.1...@xxxxxxxxx> wrote:
On Mar 9, 12:05 pm, Kay Schluehr <kay.schlu...@xxxxxxx> wrote:

On 9 Mrz., 04:51, Lie <Lie.1...@xxxxxxxxx> 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).

I know of course that syntax is Pythons holy cow but I'm not Guidos
mouthpiece and have a different perspective on some aspects of the
system for obvious reasons [1].

I agree, everybody have different perspective. But that differences is
what makes languages evolves as it'd be continuously searching for the
most optimal perspective.
.

Relevant Pages

  • Re: What c.l.pys opinions about Soft Exception?
    ... print "SoftException %s caught"%e ... entered and a continuation is created that returns to the catch block ... Exception can be added to the language silentlyso that new ... You can't inspect the call stack for this ...
    (comp.lang.python)
  • Re: What c.l.pys opinions about Soft Exception?
    ... print "SoftException %s caught"%e ... entered and a continuation is created that returns to the catch block ... Exception can be added to the language silentlyso that new ... I know of course that syntax is Pythons holy cow but I'm not Guidos ...
    (comp.lang.python)
  • Re: What c.l.pys opinions about Soft Exception?
    ... check whether it have a matching except clause. ... BException has the type AException and will be caught by the except ... print "SoftException %s caught"%e ... entered and a continuation is created that returns to the catch block ...
    (comp.lang.python)
  • Re: fortran help please!!!!
    ... WGS-72 PHYSICAL AND GEOPOTENTIAL CONSTANTS ... This looks a lot like the statement continuation didn't work. ... for any reason, then indeed, this would look like gibberish (i.e. ... If your file has any tabs (or other invisible characters), ...
    (comp.lang.fortran)
  • Re: List manipulation
    ... (k (cons (car l) ... Why would you think that if you tackle the list from the end, you would have to reverse the result. ... This style of programming is called CPS (for continuation passing style), and reason for using it is often the desire to convert ordinary recursive calls to tail calls. ...
    (comp.lang.scheme)