[EMAIL PROTECTED] wrote: > Why not just allow both exception classes and exception instances to be > raised, and only instantiate-at-catch in the case of a raise of a class > and a catch with an "as" clause?
Because that doesn't solve the problem of pre-instantiated exceptions. What I'm proposing is a way of ensuring that a new instance is always created for each raise, so that a traceback can safely be attached to it -- but only if it's going to be used. > The above also looks a lot like the current syntax, but (unless I'm > mistaken) ExceptionClass will be instantiated immediately right now. I think the number of situations where it would make any difference in existing code would be very small. You'd have to go to considerable lengths to detect whether the instantiation was being done at the time of raising or the time of catching. The main difference would be that use of preinstantiated exceptions would become illegal. But this is a 3.0 suggestion, so we can cope with that if we think it's a good enough idea. > It > seems best not to change the semantics of existing syntax if not > necessary. A different syntax could be used, but it would be a big upheaval to ask everyone to un-learn the current way of raising exceptions and go back to something that we thought we had left behind as embarrassingly old-fashioned. And there wouldn't really be any option of supporting both ways, because if you can still raise a preinstantiated exception, it wouldn't be safe to attach a traceback to it, meaning we'd have to support two different ways of handling tracebacks as well. It could all get terribly messy. -- 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