Martin v. Löwis wrote: > Alex Martelli wrote: > I think the standard exception hierarchy should grow additional standard > fields. E.g. AttributeError should have attributes 'type','name', or > perhaps even 'object','name'. TypeError should have attributes > 'expected', 'actual' (or, again, 'expected', 'object').
> And so on - that might produce quite a large PEP. I don't think there's any reason to do it in one big bang. And approached individually, each such alternate constructor is a small RFE consisting of: 1. Specific C API for creating exceptions of that type with a standard message and attributes 2. Python level class method 3. New attributes on the affected object Point 3 would be optional really, since most of the gain comes from the better error messages. If extra attributes were included in such an RFE, the potential lifecycle implications of including references to actual objects rather than merely their types makes the better choice fairly obvious to me (i.e. just include the type information, since it generally tells you everything you need to know for TypeErrors and AttributeErrors). > As 3.0 missed the > chance to fix this, compatibility is also an issue. It might be possible > to overload exception constructors on the number of parameters, or using > keyword parameters for the new way of filling the exception. Or go the traditional "multiple constructor" route and provide class methods for the alternative mechanisms. > And no, I don't volunteer to write this PEP :-) Assuming I understand what you mean by "nested exceptions" correctly, they should be covered by the __context__ and __cause__ attributes in Py3k: Exception context: =========================== >>> try: ... raise IOError ... except: ... raise AttributeError ... Traceback (most recent call last): File "<stdin>", line 2, in <module> IOError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "<stdin>", line 4, in <module> AttributeError =========================== Exception cause: =========================== >>> raise AttributeError from KeyError KeyError The above exception was the direct cause of the following exception: Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError =========================== Putting it all together: =========================== >>> try: ... raise IOError ... except: ... try: ... raise KeyError ... except Exception as ex: ... raise AttributeError from ex ... Traceback (most recent call last): File "<stdin>", line 2, in <module> IOError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "<stdin>", line 5, in <module> KeyError The above exception was the direct cause of the following exception: Traceback (most recent call last): File "<stdin>", line 7, in <module> AttributeError =========================== Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ 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
