[Python-ideas] Arguments to exceptions

[Jeff Walker]

Paul,
     Indeed, nothing gets better until people change the way they do their
exceptions. Ken's suggested enhancement to BaseException does not
directly solve the problem, but it removes the roadblocks that discourage
people from passing the components to the message.

Seems to me that to address this problem, four things are needed:
1. Change BaseException. This allows people to pass the components
    to the message without ruining str(e).
2. A PEP that educates the Python community on this better way of
    writing exceptions.
3. Changes to the base language and standard library to employ the
    new approach. These would changes would be quite small and could
    be done opportunistically.
4. Time. Over time things will just get better as more people see the
    benefits of this new approach to exceptions and adopt it. And if they
    don't, we are no worse off than we are now.

And frankly, I don't see any downside. The changes he is proposing are
tiny and simple and backward compatible.

-Jeff

03.07.2017, 14:23, "Paul Moore" <p.f.moore at gmail.com>:
> On 3 July 2017 at 20:46, Jeff Walker <jeff.walker00 at yandex.com> wrote:
>>       I think you are fixating too much on Ken's example. I think I understand what he
>>  is saying and I agree with him. It is a problem I struggle with routinely. It occurs in
>>   the following situations:
>
> Possibly. I hadn't reread the original email. Having done so, I'm
> confused as to how the proposal and the example are related. The
> proposal makes no difference unless the places where (for example)
> NameError are raised are changed. But the proposal doesn't suggest
> changing how the interpreter raises NameError. So how will the
> proposal make a difference? I'd understood from the example that Ken's
> need was to be able to find the name that triggered the NameError. His
> proposal doesn't do that (unless we are talking about user-raised
> NameError exceptions, as opposed to ones the interpreter raises - in
> which case why not just use a user-defined exception?
>
> So I'm -1 on his proposal, as I don't see anything in it that couldn't
> be done in user code for user-defined exceptions, and there's nothing
> in the proposal suggesting a change in how interpreter-raised
> exceptions are created.
>
>>  1. You are handling an exception that you are not raising. This could be because
>>      Python itself is raising the exception, as in Ken's example, or it could be raised
>>      by some package you did not write.
>>  2. You need to process or transform the message in some way.
>
> Then yes, you need to know the API presented by the exception.
> Projects (and the core interpreter) are not particularly good at
> documenting (or designing) the API for their exceptions, but that
> doesn't alter the fact that exceptions are user-defined classes and as
> such do have an API. I'd be OK with arguments that the API of built in
> exceptions as raised by the interpreter could be improved. Indeed, I
> thought that was Ken's proposal. But his proposal seems to be that if
> we add a ___str__ method to BaseException, that will somehow
> automatically improve the API of all other exceptions.
>
> To quote Ken:
>
>>  However, if more than one argument is passed, you get the string representation
>>  of the tuple containing all the arguments:
>>
>>      >>> try:
>>      ... raise Exception('Hey there!', 'Something went wrong.')
>>      ... except Exception as e:
>>      ... print(str(e))
>>      ('Hey there!', 'Something went wrong.')
>>
>>  That behavior does not seem very useful, and I believe it leads to people
>>  passing only one argument to their exceptions.
>
> Alternatively, I could argue that code which uses print(str(e)) as its
> exception handling isn't very well written, and the fact that people
> do this is what leads to people passing only one argument to their
> exceptions when creating them.
>
> Look, I see that there might be something that could be improved here.
> But I don't see an explanation of how, if we implement just the
> proposed change to BaseException, the user code that Ken's quoting as
> having a problem could be improved. There seems to be an assumption of
> "and because of that change, people raising exceptions would change
> what they do". Frankly, no they wouldn't. There's no demonstrated
> benefit for them, and they'd have to maintain a mess of backward
> compatibility code. So why would they bother?
>
> Anyway, you were right that I'd replied to just the example, not the
> original proposal. I apologise for that, I should have read the thread
> more carefully. But if I had done so, it wouldn't have made much
> difference - I still don't see a justification for the proposed
> change.
>
> Paul