Message 134549 - Python tracker

➜

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

In-reply-to
Author	xuanji
Recipients	bethard, docs@python, eric.araujo, jayt, tanqazx, xuanji
Date	2011年04月27日.10:24:25
SpamBayes Score	6.522782e-11
Marked as misclassified	No
Message-id	<1303899867.28.0.142696158033.issue9938@psf.upfronthosting.co.za>

Content
I don't think it's best to create a new subclass to throw an ArgumentParserExit exception; if I read the stack trace I'd see that an ArgumentError was thrown, then caught, then an ArgumentParserExit was thrown, which IMHO is confusing. In the current design, parse_known_errors catches an ArgumentError and then exits. I propose that the user be optionally allowed to turn off the handling of ArgumentError and to handle it himself instead through an exit_on_argument_error flag. Attached patch does this. Also I think this issue falls under component 'Lib' too.

Content

I don't think it's best to create a new subclass to throw an ArgumentParserExit exception; if I read the stack trace I'd see that an ArgumentError was thrown, then caught, then an ArgumentParserExit was thrown, which IMHO is confusing. In the current design, parse_known_errors catches an ArgumentError and then exits. I propose that the user be optionally allowed to turn off the handling of ArgumentError and to handle it himself instead through an exit_on_argument_error flag. 
Attached patch does this. Also I think this issue falls under component 'Lib' too.

History
Date	User	Action	Args
2011年04月27日 10:24:27	xuanji	set	recipients: + xuanji, bethard, eric.araujo, docs@python, jayt, tanqazx
2011年04月27日 10:24:27	xuanji	set	messageid: <1303899867.28.0.142696158033.issue9938@psf.upfronthosting.co.za>
2011年04月27日 10:24:26	xuanji	link	issue9938 messages
2011年04月27日 10:24:26	xuanji	create

homepage