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? 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 appreciate when people in the Python community talk about what is useful for them and not what the imaginary Pythonista superego thinks about them and how it will be standardized in the end - if anyhow. I'd like to know if SoftExceptions would make programs more reliable in the end because people won't use them sparingly but for all kinds of events that are somewhat "irregular" ( i.e. warnings ) not just for obvious errors. It's an interesting idea to have an advanced warning system that is more responsive than just this kind of logging which is currently implemented. And I'd surely discriminate them from the current exception handling at least in the design phase. Later language changes could still be "dissolved". [1] http://www.fiber-space.de/EasyExtend/doc/EE.html -- http://mail.python.org/mailman/listinfo/python-list
