Add functionality for handling varbind errors in get command

[stveit]

Work towards fixing #261 and #212

Adds function that takes an ObjectType and raises a relevant exception if it contains an error instead of a real value. I refer to this type of error as varbind errors since they are not defined via errorStatus or errorIndication, but are defined as values inside the response varbind

This PR makes use of the new function in the get command, but should be used for all the different commands. That can be done in other PRs once this one is completed.

To fully fix #212, some changes have to be made to the juniperalarmtask, including reverting some changes made in #231.
Handling of the new errors should also be added. NoSuchObjectError is definitely relevant, but maybe NoSuchInstanceError is too? Im not too sure about the difference about these two.. I'll leave @johannaengland to complete this task

Also sneakily fixes ErrorIndication not inheriting correctly (an SNMP related exception should probably inherit from the exception specifically made to be a base exception for everything SNMP related...)

Also2, there's quite a few SNMP specific exception classes now, thoughts on putting them in their own file?

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ PYTHON	black	2		0	0.59s
✅ PYTHON	isort	2		0	0.22s
✅ PYTHON	ruff	2		0	0.01s

See detailed report in MegaLinter reports
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

MegaLinter is graciously provided by

[github-actions]

Test results

    3 files      3 suites   52s ⏱️
  388 tests   388 ✅ 0 💤 0 ❌
1 164 runs  1 162 ✅ 2 💤 0 ❌

Results for commit e940301.

♻️ This comment has been updated with latest results.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.04%. Comparing base (3f7bc0f) to head (e940301).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #262   +/-   ##
=======================================
  Coverage   99.03%   99.04%           
=======================================
  Files          50       50           
  Lines        6735     6750   +15     
=======================================
+ Hits         6670     6685   +15     
  Misses         65       65           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[lunkwill42]

Work towards fixing #261 and #212

Adds function that takes an ObjectType and raises a relevant exception if it contains an error instead of a real value. I refer to this type of error as varbind errors since they are not defined via errorStatus or errorIndication, but are defined as values inside the response varbind

This PR makes use of the new function in the get command, but should be used for all the different commands. That can be done in other PRs once this one is completed.

To fully fix #212, some changes have to be made to the juniperalarmtask, including reverting some changes made in #231. Handling of the new errors should also be added. NoSuchObjectError is definitely relevant, but maybe NoSuchInstanceError is too? Im not too sure about the difference about these two.. I'll leave @johannaengland to complete this task

Also sneakily fixes ErrorIndication not inheriting correctly (an SNMP related exception should probably inherit from the exception specifically made to be a base exception for everything SNMP related...)

Also2, there's quite a few SNMP specific exception classes now, thoughts on putting them in their own file?

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[lunkwill42]

This PR makes use of the new function in the get command, but should be used for all the different commands. That can be done in other PRs once this one is completed.

Not necessarily. In cases where the client code expects to fetch multiple values using a single operation, the client may be fine with some of the return values being errors. The client might want to keep the successfully retrieved values and make decisions about changing its queries for failed values.

This could also be a flag to a method that retrieves multiple values. The default could be to raise exceptions, but if the calling code wants to handle error values in custom ways, it could set a flag, asking the library to stay out of its business.

Also sneakily fixes ErrorIndication not inheriting correctly (an SNMP related exception should probably inherit from the exception specifically made to be a base exception for everything SNMP related...)

👍

Also2, there's quite a few SNMP specific exception classes now, thoughts on putting them in their own file?

Sure, I'd support that - but the likely cleanup here would be to split zino/snmp.py into zino/snmp/__init__.py and zino/snmp/errors.py.