Make a 2 layer error typed system

[gauron99]

Create a 2 layer system for handling errors.

layer 1. Underlying functions and frameworks used in the CLI (like client, deployer, builder etc.) will return typed errors.
layer 2. CLI will catch these errors and based on the type provided will return a technical error from within those functions and layer another CLI specific error on top for the user.

This way we can systematically have both a valid technical error and user friendly error returned to the user depending on what situation/edge case etc. is hit.

This will require creating more error types in the core of codebase. This should be accessible via all the interfaces used in the CLI so that it is not specific to them. Example: We have multiple builders and we want to have these errors consistent across all. We might have multiple deployers, same deal.

[gauron99]

I think a good suggestion to make this work would be something along the lines of the following:

Have the layer 1 (inner) error types.

This requires creating more error types alongside the already existing ones in pkg/functions/errors.go. These would be returned in the interfaces and functions used within the CLI -- meaning any deployer, builder, client functions etc. will return this type. Create as many error types necessary. These are intended to be technical, simple and straight to the point errors. Nothing CLI specific here. See already existing comment pkg/functions/errors.go lines 27-29 for a possible hint.

Have the layer 2 (outer) error types.

This layer is intended to be a CLI layer for the errors. CLI functions runXXX (in cmd/deploy.go etc.) will catch these inner errors in all its used methods, functions and interfaces and CHECK what has been returned. ( something like if err == ErrTYPE should suffice) .

These CLI functions will catch inner errors and add a CLI specific error ON TOP. This means both straight-to-the-point technical error is returned from within as well as CLI specific user-friendly error.

I think there could even be something new like cmd/errors which would contain some CLI errors if they were generic or similar enough and could be used across multiple commands.

Actionable items:

• Create new core technical error types to be used across all interfaces and functions
• Use these errors in functions, interfaces and methods like deployers,builders etc.
• Catch these errors in the CLI functions and layer on top a CLI-specific error for the user returning both

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.