skalenetwork / skalenetwork/node-cli

Improve Error Handling & Logging in Node-CLI for Enhanced Debugging

Open
#834 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
21
Forks
7
Avg merge
2d 17h
Merged PRs (30d)
5

Description

Is your feature request related to a problem? Please describe.
In the current implementation of node-cli, most functions handle errors by calling error_exit(), which prints an error message and then calls sys.exit() with a predetermined error code. This approach has several drawbacks:

  • It makes debugging and unit testing more difficult because the program abruptly terminates rather than raising informative exceptions.
  • The error messages and context are not logged in a way that makes it easy to trace the source of the problem.
  • Failing tests provide little insight into the root cause of the error, complicating maintenance and development.

Describe the solution you'd like
I propose a comprehensive overhaul of our error handling strategy in node-cli. Key changes would include:

  • Introduce Custom Exception Classes: Create a hierarchy of custom exceptions that accurately reflect the different error conditions (e.g., InvalidEnvError, NetworkValidationError, etc.).
  • Refactor Error Handling: Instead of calling error_exit() deep within our functions, have these functions raise the appropriate custom exceptions.
  • Centralize Exit Logic: At the top level of the CLI (or within a dedicated error-handling wrapper), catch these custom exceptions and then call error_exit() to exit with the proper error code. This keeps the CLI interface intact while allowing lower-level functions to be more testable.
  • Enhanced Logging: Add detailed logging (using Python’s logging module) that records error context and stack traces. This will improve our ability to debug and understand failure scenarios during both development and testing.
  • Update Unit Tests: Adjust our tests to expect these custom exceptions or to check for specific log messages rather than catching SystemExit. This will streamline our testing process and make failures more informative.

Describe alternatives you've considered

  • Retaining the current behavior of using error_exit() in most functions was considered but rejected since it makes debugging and testing more challenging.
  • Adding logging on top of the existing error_exit() behavior was also considered; however, without refactoring the error propagation mechanism, we still face difficulties in pinpointing errors during unit tests.

Additional context
This improvement will help us better capture the underlying causes of errors and significantly improve the maintainability of node-cli. Given that node-cli interacts with several SKALE components, having robust error handling and logging is crucial for long-term stability and ease of development. This update might also influence our semantic versioning, as changes to error propagation could affect consumers of node-cli. We might need to document these changes in our release notes and update our developer guidelines accordingly.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the node-cli top-level CLI and trace uses of error_exit(); review the unit tests that currently catch SystemExit. Define the exception hierarchy, centralized handling, and Python logging behavior, then update tests and the release notes or developer guidelines mentioned in the issue.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
cli, tooling
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
32/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.