Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #95275 > unrolled thread

Is this a correct way to generate an exception when getting a wrong parameter

Back to article view | Back to comp.lang.python

Contents

  Is this a correct way to generate an exception when getting a wrong parameter Cecil Westerhof <Cecil@decebal.nl> - 2015-08-12 11:06 +0200
    Re: Is this a correct way to generate an exception when getting a wrong parameter Chris Angelico <rosuav@gmail.com> - 2015-08-12 19:25 +1000
    Re: Is this a correct way to generate an exception when getting a wrong parameter Peter Otten <__peter__@web.de> - 2015-08-12 11:33 +0200
    Re: Is this a correct way to generate an exception when getting a wrong parameter Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-08-12 11:43 +0100
      Re: Is this a correct way to generate an exception when getting a wrong parameter Bernd Waterkamp <Bernd-Waterkamp@web.de> - 2015-08-12 18:42 +0200

#95275 — Is this a correct way to generate an exception when getting a wrong parameter

I have:
========================================================================
accepted_params     = {
    'pcpu',
    'rss',
    'size',
    'time',
    'vsize',
}
========================================================================

Later I use:
========================================================================
if (to_check != 'all') and not(to_check in accepted_params):
    raise Exception('Used illegal parameter: {0}.\n'
                    'Accepted ones: {1}'
                    .format(to_check, sorted(accepted_params)))
========================================================================

When using 'all' I want to do the work for all accepted parameters.
;-)

Is this a correct way to do this, or is there a better way?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [next] | [standalone]

#95277

On Wed, Aug 12, 2015 at 7:06 PM, Cecil Westerhof <Cecil@decebal.nl> wrote:
> I have:
> ========================================================================
> accepted_params     = {
>     'pcpu',
>     'rss',
>     'size',
>     'time',
>     'vsize',
> }
> ========================================================================
>
> Later I use:
> ========================================================================
> if (to_check != 'all') and not(to_check in accepted_params):
>     raise Exception('Used illegal parameter: {0}.\n'
>                     'Accepted ones: {1}'
>                     .format(to_check, sorted(accepted_params)))
> ========================================================================
>
> When using 'all' I want to do the work for all accepted parameters.
> ;-)
>
> Is this a correct way to do this, or is there a better way?

There are a couple of things I'd do slightly differently, one of which
is to raise ValueError rather than Exception; but mostly, yes, that
seems reasonable. I'd also use "x not in y" rather than "not (x in
y)", for obvious reasons of clarity. But it kinda depends on what
those params are going to be used for. Maybe you don't need to check
at all - maybe something elsewhere will have a table that maps a
parameter to something else, and absence from that table is a clear
indication that it's an invalid parameter. If at all possible, have a
Single Source Of Truth (SSOT), from which everything else derives.

ChrisA

[toc] | [prev] | [next] | [standalone]

#95278

Cecil Westerhof wrote:

> I have:
> ========================================================================
> accepted_params     = {
>     'pcpu',
>     'rss',
>     'size',
>     'time',
>     'vsize',
> }
> ========================================================================
> 
> Later I use:
> ========================================================================
> if (to_check != 'all') and not(to_check in accepted_params):
>     raise Exception('Used illegal parameter: {0}.\n'
>                     'Accepted ones: {1}'
>                     .format(to_check, sorted(accepted_params)))
> ========================================================================
> 
> When using 'all' I want to do the work for all accepted parameters.
> ;-)

Doesn't that make it an "accepted parameter"? Why not add it to the set?

> Is this a correct way to do this, or is there a better way?

I suppose you do this early in a function? Then at least choose a more 
specific exception (e. g. ValueError).

If this is about commandline arguments -- argparse can handle such 
restrictions:

$ cat demo.py
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("--check", choices=["pcpu", "rss"], default="all")
print(parser.parse_args().check)
$ python3 demo.py
all
$ python3 demo.py --check rss
rss
$ python3 demo.py --check ssr
usage: demo.py [-h] [--check {pcpu,rss}]
demo.py: error: argument --check: invalid choice: 'ssr' (choose from 'pcpu', 
'rss')

[toc] | [prev] | [next] | [standalone]

#95279

On 12/08/2015 10:33, Peter Otten wrote:
> Cecil Westerhof wrote:
>
>> I have:
>> ========================================================================
>> accepted_params     = {
>>      'pcpu',
>>      'rss',
>>      'size',
>>      'time',
>>      'vsize',
>> }
>> ========================================================================
>>
>> Later I use:
>> ========================================================================
>> if (to_check != 'all') and not(to_check in accepted_params):
>>      raise Exception('Used illegal parameter: {0}.\n'
>>                      'Accepted ones: {1}'
>>                      .format(to_check, sorted(accepted_params)))
>> ========================================================================
>>
>> When using 'all' I want to do the work for all accepted parameters.
>> ;-)
>
> Doesn't that make it an "accepted parameter"? Why not add it to the set?
>
>> Is this a correct way to do this, or is there a better way?
>
> I suppose you do this early in a function? Then at least choose a more
> specific exception (e. g. ValueError).
>
> If this is about commandline arguments -- argparse can handle such
> restrictions:
>
> $ cat demo.py
> import argparse
> parser = argparse.ArgumentParser()
> parser.add_argument("--check", choices=["pcpu", "rss"], default="all")
> print(parser.parse_args().check)
> $ python3 demo.py
> all
> $ python3 demo.py --check rss
> rss
> $ python3 demo.py --check ssr
> usage: demo.py [-h] [--check {pcpu,rss}]
> demo.py: error: argument --check: invalid choice: 'ssr' (choose from 'pcpu',
> 'rss')
>
>

The wonderful http://docopt.org/ makes this type of thing a piece of 
cake.  I believe there's a newer library that's equivalent in 
functionality to docopt but I can never remember the name of it, anybody?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#95295

Mark Lawrence schrieb:

> The wonderful http://docopt.org/ makes this type of thing a piece of 
> cake.  I believe there's a newer library that's equivalent in 
> functionality to docopt but I can never remember the name of it, anybody?

Never used it, but "Click" is another choice: http://click.pocoo.org/4/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web