A question about the posibility of raise-yield in Python

rurpy at yahoo.com rurpy at yahoo.com
Wed Jun 30 19:20:10 EDT 2010


On Jun 30, 10:48 am, John Nagle <na... at animats.com> wrote:
> On 6/30/2010 12:13 AM, Дамјан Георгиевски wrote:
>
> >> A 'raise-yield' expression would break the flow of a program just like
> >> an exception, going up the call stack until it would be handled, but
> >> also like yield it would be possible to continue the flow of the
> >> program from where it was raise-yield-ed.
>
>      Bad idea.  Continuing after an exception is generally troublesome.
> This was discussed during the design phase of Ada, and rejected.
> Since then, it's been accepted that continuing after an exception
> is a terrible idea.  The stack has already been unwound, for example.
>
>      What you want, in in the situation you describe, is an optional
> callback, to be called in case of a fixable problem. Then the
> caller gets control, but without stack unwinding.

Strangely I was just thinking about something similar (non-stack
the other day.  Something like

def caller():
  try: callee()
  except SomeError, exc: ...
  else exclist: ...

def callee():
  if error: raise SomeError()
  else raise2: SomeWarning()

raise2 would create an exception object but unlike
raise, would save in it a list somewhere and when
callee() returned normally, the list would be made
asvailable to caller, possibly in a parameter to
the try/except "else" clause as shown above.  Obviously
"raise2" is a placeholder for "some way to signal that
this is a non-stack-unwinding exception."

The use case addressed is to note exceptional conditions
in a function that aren't exceptional enough to be fatal
but which the caller may or may not care about.
Siminlar to the Warning module but without the brokenness
of doing io.  Integrates well with the existing way of
handling fatal exceptions.

No idea if something like this even remotely feasible.



More information about the Python-list mailing list