Current error handling has been minimal as the project is in early development.
Right now, errors are just printed to the user which isn't very user friendly as many of these messages are hard to read, or aren't understandable to people know aren't knowledgeable on Rust.
Solution
To make errors better, the CLI should support a function that can send errors to the user, then each module can report errors through the CLI.
Error handling should match on different error to detect what type of errors have occurred and relay why to the user.
Error messages should convey the actual error at hand (PermissionError, FileNotFound, etc) and then suggest a reason why (assumptions can be made for this).
Error tags
I suggest three error tags: ERROR, ISSUE, ABORT. Each of these has varying serverity: ISSUE; for small issues that the program should be able to recover from, ERROR; when something does not go right and may or may not be recoverable, ABORT; when an issue isn't recoverable and the program is going to exit.
Example:
[ISSUE] A FileNotFoundError occurred in the Config module, maybe a "config.toml" does not exist?
Current error handling problem
Current error handling has been minimal as the project is in early development. Right now, errors are just printed to the user which isn't very user friendly as many of these messages are hard to read, or aren't understandable to people know aren't knowledgeable on Rust.
Solution
To make errors better, the CLI should support a function that can send errors to the user, then each module can report errors through the CLI. Error handling should match on different error to detect what type of errors have occurred and relay why to the user. Error messages should convey the actual error at hand (PermissionError, FileNotFound, etc) and then suggest a reason why (assumptions can be made for this).
Error tags
I suggest three error tags: ERROR, ISSUE, ABORT. Each of these has varying serverity: ISSUE; for small issues that the program should be able to recover from, ERROR; when something does not go right and may or may not be recoverable, ABORT; when an issue isn't recoverable and the program is going to exit.
Example: