[Python-3000] exceptions with keyword arguments

[tomer filiba]

Brett writes:
> as specified in the PEP.  But that does not stop someone from overriding
> BaseException in a subclass, as some built-ins do already.  So you can
> easily add your filename attribute.::
>
>  def __init__(self, filename):
>      self.filename = filename
>      BaseException.__init__(self, "%s does not exist" % filename)

Guido writes:
> Some standard exceptions will provide more attributes (e.g. errno,
> filename, strerror etc.) and ways to provide values for those via the
> constructor. It's up to each subclass of BaseException to define the
> appropriate costructor signature.

well, if this is the case, i'm happy with that. i was afraid it will end up
like today's AttributeError, where you must parse the message in order
to get the missing attribute's name. as long as exceptions will hold
information as attributes, i have no complaints.

----

still, what about ArgumentError? don't you think it's worth adding?
don't you think TypeError is misleading in that context?


-tomer

On 5/19/06, Guido van Rossum <guido at python.org> wrote:
>
> On 5/18/06, Josiah Carlson <jcarlson at uci.edu> wrote:
> >
> > "tomer filiba" <tomerfiliba at gmail.com> wrote:
> > > On 5/17/06, Brett Cannon <brett at python.org> wrote:
> > > > And I brought this up with Guido once and he was not enthusiastic
> > > > about it.  Basically, keep exceptions simple.  They are important
> > > > and basic enough to keep it simple.  If you want fancier support,
> > > > subclass Exception and add the support you want.
> > >
> > > well, if guido pronounced on it than i guess it's settled, but why do
> you
> > > condsider *args to be simple and **kwargs not as simple? don't you
> > > think "ex.filename" is simpler/clearer than "ex[1]"?
> >
> > From what I understand of Brett's post, ex[1] won't be available anymore
> > either.
>
> Correct.
>
> > While it would be convenient for inspecting exceptions when they are
> > caught via ex.attr, creating exceptions with keyword arguments seems
> > like it would be a bit if a pain.
>
> All this has little to do with exceptions per se. It's just about
> classes, subclasses, constructor signatures, and instance attributes.
>
> There's no need for the attributes to match the keywords, nor is there
> a need to access values using x[i] notation when they were passed to
> the constructor sequentially.
>
> BaseException (in py3k) defines one positional argument and one
> attribute named message.
>
> Some standard exceptions will provide more attributes (e.g. errno,
> filename, strerror etc.) and ways to provide values for those via the
> constructor. It's up to each subclass of BaseException to define the
> appropriate costructor signature.
>
> (Is this perhaps yet another case of the misunderstanding that the
> constructor signature of a subclass must be compatible with that of
> the base class? Assuming single inheritance there's no need for that
> restriction.)
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20060519/3b334ac6/attachment.html