I'm asking about people in c.l.py's opinion about a _probably_ very Pythonic way of doing something if such features is implemented. It is to be known that I'm not a Python expert and actually relatively new to Python programming, so probably I'm just not thinking pythonic enough yet or this feature might already exist somewhere in a different name. Anyway, I'm just asking for opinions, tell me problems I haven't foreseen, or whether such things would be hard to implement, or whether you think the idea is great or plain bad (and why).
Soft Exception What is "Soft Exception"? Soft Exception is an exception that if is unhandled, pass silently as if nothing happened. For example, if a variable turns into NoneType, it'll raise Soft Exception that it have become NoneException, programmers that wants to handle it can handle it with a try...except block while programmers that doesn't care about it (or know it won't be a problem to his code) can just leave the code as it is. Soft Exception differs from Hard Exceptions (the regular Exception) in a way that Hard Exception must be handled at all cost or the program will be terminated while Soft Exception allow programmers not to handle it if they don't want to. Soft Exception is similar to an event-based system, although Soft Exception can only be handled by codes above it while Event-based system can be handled by anyone aware of the handle pool. The Soft Exception can also be thought as a Warning to the codes above it that it has done something that the codes above might want to know. Implementation: Simple implementation might be done by catching all exceptions at the highest level, then filtering which exceptions would be stopped (Soft Exception) and which exceptions will be reraised and terminate the program (Hard Exception). This is simple and can be easily implemented but is inefficient as that means all soft exceptions must bubble through its way to the top to find out if it is Soft or Hard. 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. Syntax change is probably unneeded and a Soft Exception class may be created by inheriting from BaseSoftException class. Problems: - If the raising statement is a complex statement (like function call) instead of just a simple statement (like assignment from an expression) the exception might catch a similar soft exceptions from deep _inside_ the function call and handle it as if it happened in the code it's protecting. This problem can be solved by raising Soft Exception only once except if explicitly reraised (perhaps through except SoftException: raise). This can be done by modifying a flag that is turned off (Falsed) if the Soft Exception is raised and turned on again (Trued) if the Soft Exception is reraised. Normal Exceptions (Hard Exceptions) would have this flag turned off (Falsed) if it is handled and turned on (Trued) again if it is reraised. - To be half useful, soft exceptions have to be raised everywhere here and there, not just here and here only. This might require a massive change in current codes, or at least in Python's official libraries. - Irresponsible programmers. Sometimes lazy programmers might decides to be lazy and make all exceptions soft so he doesn't have to handle it. Ideology Base: - EAAP: Easier to apologize than to ask permission. Others: - Sometimes it might be useful to convert a Soft Exception into Hard Exception or vice versa. -- http://mail.python.org/mailman/listinfo/python-list
