Guido van Rossum wrote: > I'm afraid we're back at square zero; perhaps we should keep the > existing (type, value, traceback) API
Whatever happens, we should be able to get that down to at most two things: (exception, context) where exception is either a class or an instance, and context includes the traceback and anything else that varies from one raising to another. > rather than going for radical > (and unproven) innovation like "except E as v with tb: <block>". The "with something" clause isn't mutually exclusive with that -- rather it goes hand-in-hand as a nicer way of getting hold of the context than calling sys.exc_info(). I'd consider it an optional extra. > "except E as v with tb in context for cause" anyone? :-) I was thinking more of except E as v with context: and context would have attributes such as traceback, cause, etc. (Although calling it a "context" could be seriously confusing, considering we also have a "with" statement having something called a context that's completely different.) > The one thing that makes me not want to give up yet is that having the > traceback, context, cause etc. as attributes of the exception object > would seem to make the API for handling exceptions that much cleaner, If we can get it down to a 2-tuple, with no fudging around to allow for sometimes having the args separate from the type but not always, that should simplify it considerably. One thing I would like to get out of it if possible is the chance to raise and catch an exception class without instantiating it at all under favourable circumstances. That should be possible if we allow the first item of the tuple to be either a class or instance, and not bother instantiating if it's a class and gets caught with except E: or except E with context: -- Greg _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
