Don't hide errors on normal execution
Closed this issue · 2 comments
People are trying to test their codius host setups using the example on the codius tutorial and/or codius-example repo.
In the failure case, the cli just returns empty - the user doesn't know what went wrong.
They can get the full log using DEBUG=*
, but that's not very intuitive (I actually discovered this looking into the source code - good ol debug
module - even the readme for this repo doesn't mention it).
Strong urge that errors are outputted to console with a short blurb on how to get the full debug logs.
Agreed. Here are some of my thoughts on best practices.
debug
for very verbose debug messages
console.info
for regular messages you would want most users to see
console.warn
for warnings
console.error
for serious errors
And, personally, I also use console.log
for temporary debug statements I plan to remove before committing.
For upstream modules, it's good practice to avoid console.info
to avoid unwanted console output. (console.warn
and console.error
are still fine to warn the user that something went wrong.) This module, codius
, should try to gather enough information so it can console.info
useful output about what it's doing. That way, when something does go wrong, there is some context about what it was attempting.
For all log messages of any kind, always include useful variables, not just an error message. Best practice is to use a key=value format to make the log more easily parseable. I like this simple format: something happened. key1=value1 key2=value2
For the top-level user-facing module, I created riverpig which is a simple logging library that supports namespacing (like debug
), different log levels, and colored output. Could be useful for this module, unless we want to put more effort into highly customized console output.
Improved error handing in the Codius CLI 3.0.0, riverpig is used and all errors are surfaced to the user when they occur without the need for DEBUG=*.