Hi all,
I am fairly new to python (ie < 2 years). I have a question about
pylint. I am running on windows 10/11, python 3.10.11.

Here's what I'm trying to do:
I am using robocopy to to copy a set of files to/from a LAN location and
my desktop(s). Here is the partial code:

p = subprocess.run(["robocopy.exe",
STORE_LOCATION, NEWS_LOCATION,
"/NFL", "/NDL", "/NJH", "/NJS", "/NP", "/XF",
"msgFilterRules.dat",
"xmsgFilterRules.dat"], check=False)

# this is necessary because Windows Robocopy returns
# various return codes for success.
if p.returncode >= 8:
raise Exception(f'Invalid result: {p.returncode}')

It actually runs fine. But pylint is not having it. I get:

win_get_put_tb_filters.py:61:12: W0719: Raising too general exception:
Exception (broad-exception-raised)

But the code I have written does exactly what I want. If the returncode
is 7 or less, then I have success. If the returncode is 8 or above
there is a failure and I want to see what the returncode is.

Trying to read the python Exception docs is mind bending. Any help
would be appreciated.

Richard

rsutton <rsutton43@comcast.net> wrote:
> Hi all,
> I am fairly new to python (ie < 2 years). I have a question about
> pylint. I am running on windows 10/11, python 3.10.11.
[...]
> if p.returncode >= 8:
> raise Exception(f'Invalid result: {p.returncode}')
>
> It actually runs fine. But pylint is not having it. I get:
>
> win_get_put_tb_filters.py:61:12: W0719: Raising too general exception:
> Exception (broad-exception-raised)

pylint is just a linter, ignore it if the code works and you like it the
way it is.

pylint complains because you use Exception. Use e.g. RuntimeException to
silence it.

rsutton <rsutton43@comcast.net> writes:
>Trying to read the python Exception docs is mind bending. Any help
>would be appreciated.

After "import builtins", "_ =[ print( x )for x in dir( builtins )
if 'rror' in x or 'xception' in x ]" (one long line without the
outer quotation marks) prints some prominent exception types. After
manually removing those that do not seem to apply, I am left with:

"AssertionError",
"ChildProcessError",
"EnvironmentError",
"IOError",
"LookupError",
"OSError",
"OverflowError",
"RuntimeError",
"SyntaxError",
"SystemError",
"ValueError", and
"WindowsError".

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>outer quotation marks) prints some prominent exception types. After
>manually removing those that do not seem to apply, I am left with:
>"AssertionError",
>"ChildProcessError",
....

"Manually removing" above was meant to be a fast first pass,
where I only excluded exception types that were obviously
inappropriate. It is now to be followed by a search for the
appropriate exception types among those exception types left.

On 10/25/2023 11:06 AM, Stefan Ram wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>> outer quotation marks) prints some prominent exception types. After
>> manually removing those that do not seem to apply, I am left with:
>> "AssertionError",
>> "ChildProcessError",
> ...
>
> "Manually removing" above was meant to be a fast first pass,
> where I only excluded exception types that were obviously
> inappropriate. It is now to be followed by a search for the
> appropriate exception types among those exception types left.
>
>
@Rene & @Stefan,
I really appreciate the guidance provided. By replacing Exception with
RuntimeError, pylint seems happy! More specificity, I guess. I know
that I could have ignored the pylint exceptions, but I want to use this
as a learning experience. I looks like I have a lot of reading to do on
exception handling. IMO all of the try/except code looks quite clumsy to
me. It may be excellent for some tasks but to me, it looks quite
inelegant. Like I said, I have a lot to learn.

Thank you both for your guidance.

Richard

On Wed, Oct 25 2023 at 11:49:12 AM, rsutton <rsutton43@comcast.net> wrote:
> On 10/25/2023 11:06 AM, Stefan Ram wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>> outer quotation marks) prints some prominent exception types. After
>>> manually removing those that do not seem to apply, I am left with:
>>> "AssertionError",
>>> "ChildProcessError",
>> ...
>> "Manually removing" above was meant to be a fast first pass,
>> where I only excluded exception types that were obviously
>> inappropriate. It is now to be followed by a search for the
>> appropriate exception types among those exception types left.
>>
> @Rene & @Stefan,
> I really appreciate the guidance provided. By replacing Exception
> with RuntimeError, pylint seems happy! More specificity, I guess. I
> know that I could have ignored the pylint exceptions, but I want to
> use this as a learning experience. I looks like I have a lot of
> reading to do on exception handling. IMO all of the try/except code
> looks quite clumsy to me. It may be excellent for some tasks but to
> me, it looks quite inelegant. Like I said, I have a lot to learn.
>

>From what you've described of your problem, it seems like a small-ish
utility program you're writing for your own use. You don't need any
`try`...`except` blocks in such code. You just let the exception stop
your program.

--
regards,
kushal

On 10/25/2023 11:49 AM, rsutton via Python-list wrote:
> On 10/25/2023 11:06 AM, Stefan Ram wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>> outer quotation marks) prints some prominent exception types. After
>>> manually removing those that do not seem to apply, I am left with:
>>> "AssertionError",
>>> "ChildProcessError",
>> ...
>>
>>    "Manually removing" above was meant to be a fast first pass,
>>    where I only excluded exception types that were obviously
>>    inappropriate. It is now to be followed by a search for the
>>    appropriate exception types among those exception types left.
>>
>>
> @Rene & @Stefan,
> I really appreciate the guidance provided.  By replacing Exception with
> RuntimeError, pylint seems happy!  More specificity, I guess.  I know
> that I could have ignored the pylint exceptions, but I want to use this
> as a learning experience.  I looks like I have a lot of reading to do on
> exception handling. IMO all of the try/except code looks quite clumsy to
> me.  It may be excellent for some tasks but to me, it looks quite
> inelegant.  Like I said, I have a lot to learn.

In this particular case you could probably just handle the return result
from robocopy right there. Of course, it depends on the rest of the
code. It probably doesn't really need an exception, and if you want to
handle it in the calling function, you could just return the result as a
boolean:

return p.returncode < 8 # Reversed the test since a return of "True"
# would make more sense as a return code

> Thank you both for your guidance.
>
> Richard
>

On 26/10/2023 04.49, rsutton via Python-list wrote:
> On 10/25/2023 11:06 AM, Stefan Ram wrote:
>> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>> outer quotation marks) prints some prominent exception types. After
....

>>    "Manually removing" above was meant to be a fast first pass,
>>    where I only excluded exception types that were obviously
>>    inappropriate. It is now to be followed by a search for the
>>    appropriate exception types among those exception types left.
>>
>>
> @Rene & @Stefan,
> I really appreciate the guidance provided.  By replacing Exception with
....

It would appear that (at least one message) did not make it to email -
neither to the list-archive.

People wishing to learn are unable to benefit a response, if it is not
sent to the list!

--
Regards,
=dn

Rene Kita <mail@rkta.de> wrote:
> rsutton <rsutton43@comcast.net> wrote:
>> Hi all,
>> I am fairly new to python (ie < 2 years). I have a question about
>> pylint. I am running on windows 10/11, python 3.10.11.
> [...]
>> if p.returncode >= 8:
>> raise Exception(f'Invalid result: {p.returncode}')
>>
>> It actually runs fine. But pylint is not having it. I get:
>>
>> win_get_put_tb_filters.py:61:12: W0719: Raising too general exception:
>> Exception (broad-exception-raised)
>
> pylint is just a linter, ignore it if the code works and you like it the
> way it is.
>
> pylint complains because you use Exception. Use e.g. RuntimeException to
> silence it.
^^^^^^^^^^^^^^^^

Ingrid says it's a RuntimeError, not RuntimeException.

On 10/26/23 03:04, Rene Kita via Python-list wrote:
> Rene Kita <mail@rkta.de> wrote:
>> rsutton <rsutton43@comcast.net> wrote:
>>> Hi all,
>>> I am fairly new to python (ie < 2 years). I have a question about
>>> pylint. I am running on windows 10/11, python 3.10.11.
>> [...]
>>> if p.returncode >= 8:
>>> raise Exception(f'Invalid result: {p.returncode}')
>>>
>>> It actually runs fine. But pylint is not having it. I get:
>>>
>>> win_get_put_tb_filters.py:61:12: W0719: Raising too general exception:
>>> Exception (broad-exception-raised)
>>
>> pylint is just a linter, ignore it if the code works and you like it the
>> way it is.
>>
>> pylint complains because you use Exception. Use e.g. RuntimeException to
>> silence it.
> ^^^^^^^^^^^^^^^^
>
> Ingrid says it's a RuntimeError, not RuntimeException.

Meanwhile, the purpose of this complaint from pylint (and notice it's a
"warning", not an "error", so take that for what it's worth), is that
you usually want to convey some information when you raise an exception.
Of course, you can put that into the message you pass to the class
instance you raise, but the type of exception is informational too.
Raising just "Exception" is equivalent to saying "my car is broken",
without specifying that the starter turns but won't "catch", or starts
but the transmission won't engage, or the battery is dead, or .... so
it's *advising* (not forcing) you to be more informative.

Mats Wichmann <mats@wichmann.us> writes:
>Of course, you can put that into the message you pass to the class
>instance you raise, but the type of exception is informational too.

|Note: Exception messages are not part of the Python API.
|Their contents may change from one version of Python to the
|next without warning and should not be relied on by code
|which will run under multiple versions of the interpreter.
The Python Language Reference, Release 3.13.0a0

So, when it comes to the standard library, /only/ the type
of exception is informational (for interpretation by code).