The top-level commands in the project (e.g., pokemon, move, types, etc.) currently do not return errors. Instead, they rely on os.Exit() when something goes wrong.
Refactoring those command functions to return errors instead of exiting the process directly is the way to go. This change will make the code more testable, composable, and easier to maintain.
Current Behavior
Command functions call os.Exit() when an error occurs, for example:
if err := someFunction(); err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
Solution
Update the command functions to return error (or (string, error) when applicable), and move the responsibility of calling os.Exit() to the top-level entry point.
func PokemonCommand() (string, error) {
if err := validateInput(); err != nil {
return "", fmt.Errorf("validation failed: %w", err)
}
// ...main logic...
return output.String(), nil
}
The top-level commands in the project (e.g.,
pokemon,move,types, etc.) currently do not return errors. Instead, they rely onos.Exit()when something goes wrong.Refactoring those command functions to return errors instead of exiting the process directly is the way to go. This change will make the code more testable, composable, and easier to maintain.
Current Behavior
Command functions call
os.Exit()when an error occurs, for example:Solution
Update the command functions to return error (or (string, error) when applicable), and move the responsibility of calling os.Exit() to the top-level entry point.