[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZemJZPySuUyGlMTu@gmail.com>
Date: Thu, 7 Mar 2024 01:31:16 -0800
From: Breno Leitao <leitao@...ian.org>
To: Donald Hunter <donald.hunter@...il.com>, kuba@...nel.org
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
Jacob Keller <jacob.e.keller@...el.com>,
Jiri Pirko <jiri@...nulli.us>, Stanislav Fomichev <sdf@...gle.com>,
donald.hunter@...hat.com
Subject: Re: [PATCH net-next v3 2/6] tools/net/ynl: Report netlink errors
without stacktrace
Hello Donald,
On Wed, Mar 06, 2024 at 11:10:42PM +0000, Donald Hunter wrote:
> ynl does not handle NlError exceptions so they get reported like program
> failures. Handle the NlError exceptions and report the netlink errors
> more cleanly.
>
> Example now:
>
> Netlink error: No such file or directory
> nl_len = 44 (28) nl_flags = 0x300 nl_type = 2
> error: -2 extack: {'bad-attr': '.op'}
>
> Example before:
>
> Traceback (most recent call last):
> File "/home/donaldh/net-next/./tools/net/ynl/cli.py", line 81, in <module>
> main()
> File "/home/donaldh/net-next/./tools/net/ynl/cli.py", line 69, in main
> reply = ynl.dump(args.dump, attrs)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
> File "/home/donaldh/net-next/tools/net/ynl/lib/ynl.py", line 906, in dump
> return self._op(method, vals, [], dump=True)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File "/home/donaldh/net-next/tools/net/ynl/lib/ynl.py", line 872, in _op
> raise NlError(nl_msg)
> lib.ynl.NlError: Netlink error: No such file or directory
> nl_len = 44 (28) nl_flags = 0x300 nl_type = 2
> error: -2 extack: {'bad-attr': '.op'}
Basically this is just hidding the stack, which may make it harder for
someone not used to the code to find the problem.
Usually fatal exception is handled to make the error more meaningful,
i.e, better than just the exception message + stack. Hidding the stack
and exitting may make the error less meaningful.
On a different topic, I am wondering if we want to add type hitting for
these python program. They make the review process easier, and the
development a bit more structured. (Maybe that is what we expect from
upcoming new python code in netdev?!)
If that is where we want to go, this is *not*, by any mean, a blocker to
this code. Maybe something we can add to our public ToDo list (CC:
Jakub).
Powered by blists - more mailing lists