Comments (13)
Hi,
My strategy has always been that any exception that is related to an error in the end user's input should result in an ArgException. That way, developers can have one catch block where it's always safe to show the message to the user and then print out the program's usage.
In other cases, the natural exception should flow through. The one example you show for the Assembly exception is a bug on my part. It should be changed to something Like an InvalidOperationException.
There are some cases where I intentionally catch some exceptions and then wrap them in an ArgException, but maybe you're suggesting that I don't do that for the user.
Can you please be more specific about the scenarios where you would expect a more specific exception?
Thanks,
Adam
from powerargs.
Hello, Adam! I'll try to be more specific this time.
When end user's input is somehow wrong - I have ArgException. At this point my reaction can be:
- just show exception's message to user
- show some generic "everything is bad and you should feel bad" message
But if I want to have another complicated reaction - I don't have full information about occurred exception. For example, it's needed to show different internationalized messages according to the malformed end-user's input: one message for unexpected argument, another one for duplicated argument, etc.
Currently ArgException can be thrown when (mentioning just user input issues):
- argument has been specified twice
- wrong argument notation (
/
,-
) - unexpected argument
- wrong value for an argument
- missing required argument
- arguments' validation issues
And with instance of caught ArgException we can't know what've happened exactly.
I'm proposing to create an exception hierarchy - with different more specific exceptions derived from ArgException. E.g. UnexpectedArgException that has argument name property inside, etc. So, it should be possible to catch base one (react generally, or switch on type) or even have multiple catches per types.
ps. http://msdn.microsoft.com/en-us/library/vstudio/ms229064(v=vs.100).aspx
Consider providing exception properties for programmatic access to extra information (besides the message string) relevant to the exception.
from powerargs.
I think you make fair points. I like giving the dev the choice between showing the simple message or doing special handling if they choose the catch the specific exceptions. I'll consider this for an upcoming update (or feel free to take a stab at it, just let me know first so we don't both go do the same thing.
Thanks,
Adam
from powerargs.
I can work this out on upcoming weekend, wait for the pull request :)
from powerargs.
Sweet! Thanks a lot.
from powerargs.
Sorry for being inactive, was kinda fully loaded with my work. I'll work this out asap! 😉
from powerargs.
No problem
from powerargs.
Looks like it's been a little while. Anyone mind if I work on this? I'll wait a few days to hear back. If I don't read of any objections by March 25th I'll work on it on the 25 and 26th of March. Also any contribution guidelines?
from powerargs.
I assume you mean May 25, and that sounds reasonable. No real guidelines since there has not been much contribution. Maybe send a few sentences over regarding your strategy and which exceptions you plan to add. That way we can have some discussion before you spend time writing code.
from powerargs.
Yes I did mean May 25th (I seem to mix those two months up for some reason). As far as strategy. Just going through and review any thrown ArgExceptions to see if the message or situation are in multiple spots (valid values for example) or if they are significant situations. All of these would derive from ArgException to allow existing code to function normally. I don't believe adding any additional properties to these new exceptions would be needed.
First pass in about 10 minutes produced this list:
- UnexpectedArgumentException: For both named and unamed arguments
- DuplicateArgumentException: For "Argument specified more than once"
- MissingArgumentException: For "The argument [argument] is required"
- UnknownActionArgumentException: For "Unknown action"
- MissingActionArgumentException: For "No action was specified" (This might just become 'MissingArgumentException')
- QueryInvalidArgumentException: For "Could not compile your query"
I would recommend when "PowerArgs could not determine the name of your executable" that an InvalidOperationException be thrown instead of an ArgException. It's not a problem with a command line arg, it's a problem with the operational usage of the library at that moment, much like the message points out.
The ArgRevivers has a bit of inconsistency in using FormatException vs ArgException with regard to DateTime revival. How about just staying with FormatException since that seems to be the real problem anyway?
One that I am having a hard time pinning down in my mind is invalid argument values (ArgRange for example) and general argument validation problems (ArgExistingDirectory). At first I though of doing
* InvalidValueArgumentException for values that are 'well formed' but out of range (numbers, enums, length)
* ArgumentValidationException for any other general problem with the value (folder/file not found)
But since they both have 'Valid' in them I may just use the second one. Any suggestions would be appreciated.
This is just a first pass, if it feels like I'm going to far splitting out the exceptions just let me know.
from powerargs.
Sounds good.
From: davidroberts63mailto:[email protected]
Sent: 5/24/2013 12:46 AM
To: adamabdelhamed/PowerArgsmailto:[email protected]
Cc: Adam Abdelhamedmailto:[email protected]
Subject: Re: [PowerArgs] Exceptions hierarchy (#11)
Yes I did mean May 25th (I seem to mix those two months up for some reason). As far as strategy. Just going through and review any thrown ArgExceptions to see if the message or situation are in multiple spots (valid values for example) or if they are significant situations. All of these would derive from ArgException to allow existing code to function normally. I don't believe adding any additional properties to these new exceptions would be needed.
First pass in about 10 minutes produced this list:
- UnexpectedArgumentException: For both named and unamed arguments
- DuplicateArgumentException: For "Argument specified more than once"
- MissingArgumentException: For "The argument [argument] is required"
- UnknownActionArgumentException: For "Unknown action"
- MissingActionArgumentException: For "No action was specified" (This might just become 'MissingArgumentException')
- QueryInvalidArgumentException: For "Could not compile your query"
I would recommend when "PowerArgs could not determine the name of your executable" that an InvalidOperationException be thrown instead of an ArgException. It's not a problem with a command line arg, it's a problem with the operational usage of the library at that moment, much like the message points out.
The ArgRevivers has a bit of inconsistency in using FormatException vs ArgException with regard to DateTime revival. How about just staying with FormatException since that seems to be the real problem anyway?
One that I am having a hard time pinning down in my mind is invalid argument values (ArgRange for example) and general argument validation problems (ArgExistingDirectory). At first I though of doing
* InvalidValueArgumentException for values that are 'well formed' but out of range (numbers, enums, length)
* ArgumentValidationException for any other general problem with the value (folder/file not found)
But since they both have 'Valid' in them I may just use the second one. Any suggestions would be appreciated.
This is just a first pass, if it feels like I'm going to far splitting out the exceptions just let me know.
Reply to this email directly or view it on GitHub:
#11 (comment)
from powerargs.
Thanks for being good to work with. FYI I have written a blog post about this contribution (my attempt at blogging more often) at http://davidroberts63.bitbucket.org/blog/2013/05/28/fork-and-pull-powerargs/
from powerargs.
Cool blog post. Sorry, I already fixed that multiple shortcuts issue so you won't be able to take that one. But feel free to suggest other features, improvements, bugs, etc.
from powerargs.
Related Issues (20)
- Add support for a warning on usage of obsolete enum value HOT 1
- Implementation of ContextAssistSearch doesn't get initialized HOT 1
- Slash (/) with positional arguments running on Linux & MacOS HOT 2
- How to specify command line parameters with double dashes (eg. --help) HOT 1
- Boolean args as 'flags'? HOT 1
- String args with 'null' as default throw unhandled exception HOT 1
- New Release Pending? HOT 1
- validation message missing for ArgCantBeCombinedWith HOT 1
- Prompting for input despite PromptIfMissing=false on Required arg HOT 3
- Allow zero-length list of argument values to be terminated by next option
- How to parse into an array? HOT 2
- Issue with scrolling in console HOT 2
- Issue running on Linux HOT 3
- Scrolling and background issues on 4.0.0. Works on 3.6.0 HOT 2
- Some links broken in README.md HOT 1
- Validator only checks first item in List arguments HOT 1
- Release 4.0.2 is not strongnamed (4.0.0 is, as well as 3.6.x) HOT 1
- Change executable name in 'help'?
- bool reviver not working
- Use param label as value
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from powerargs.