On 4 July 2017 at 06:08, Nick Coghlan <ncogh...@gmail.com> wrote: > On 4 July 2017 at 09:46, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: >> Paul Moore wrote: >>> >>> As noted, I disagree that people are not passing components because >>> str(e) displays them the way it does. But we're both just guessing at >>> people's motivations, so there's little point in speculating. >> >> >> I've no doubt that the current situation encourages people >> to be lazy -- I know, because I'm guilty of it myself! >> >> Writing a few extra lines to store attributes away and format >> them in __str__ might not seem like much, but in most cases >> those lines are of no direct benefit to the person writing >> the code, so there's little motivation to do it right. > > So isn't this a variant of the argument that defining well-behaved > classes currently involves writing too much boilerplate code, and the > fact that non-structured exceptions are significantly easier to define > than structured ones is just an example of that more general problem? > > I personally don't think there's anything all *that* special about > exceptions in this case - they're just a common example of something > that would be better handled as a "data record" type, but is commonly > handled as an opaque string because they're so much easier to define > that way.
Yes, that's what I was (badly) trying to say. I agree that we could hide a lot of the boilerplate in BaseException (which is what Ken was suggesting) but I don't believe we yet know the best way to write that boilerplate, so I'm reluctant to put anything in the stdlib until we do know better. For now, experimenting with 3rd party "rich exception" base classes seems a sufficient option. It's possible that more advanced methods than simply using a base class may make writing good exception classes even easier, but I'm not sure I've seen any evidence of that yet. Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
