[bugfix] Straighten out command-line error handling

[fako1024]

What I've done:

• Replaced all manual error handling / output in the cobra entrypoint function to simply return the error to the caller
• Handle any error from that function in Execute(), using "our" logger with its Fatalf() method
• Initialize our logger directly in init() instead of via cobra (to ensure it's already initialized if the error occurs before cobra can call the initializer)

@els0r For now I've kept this a draft because there are two open questions IMHO:

• Should we maybe add a special formatter for the command line tool(s)? Right now we throw a message like this:

ts=2023-04-11T11:23:51.976+02:00 level=fatal msg="Error running query: failed to prepare query: failed to parse query type: Unknown attribute name: 'protod'" version=872abf81

TBH I don't think that someone running a CLI expects a "logger" style response but rather something like:

Error running query: failed to prepare query: failed to parse query type: Unknown attribute name: 'protod'

• The same changes should probably be applied to global-query (because the same problem about not notifying errors happens there as indicated in global-query #43 )

What's your take on those open questions?

Closes #104

[els0r]

Thanks for looking into this. As for your question about the custom formatter: it absolutely makes sense, but only where we log an error that is propagated from the entrypoint (e.g. where we previously did fmt.Frpintf(os.Stderr, ...).

Writing that slog.Handler should be trivial, or even fun. Which does bring me to another point though: I am almost certain that we need to split up initialization of the logging library and instantiation. In the sense that we can do:

logging.New(level, encoding, ...opts) and get a new *logging.L object with all the pretty handlers attached. And of course NewFromContext. The function signature is the same as for Init because you want to retain maximum control over what the logger does.

The Init function will then be nothing but a wrapper around New.

This would allow us to create a logger for only the CLI stuff, while the rest of the logging functionality is untouched.

[els0r]

@fako1024 : see latest PR on logging. Sets the ground work for writing and using the PlainHandler only inside the main.go function of the respective tools.

[els0r]

Changes requested because we need the:

• plain/CLI logging handler (I prefer plain because it's closer to what the logger does or doesn't do)
• use the logger only in Execute
• if err stuff because it'll create merge conflicts with global-query #43 that are tedious to fix

[els0r]

Good to go from my end. Feel free to merge when available.

[fako1024]

Good to go from my end. Feel free to merge when available.

Awesome, thanks a lot for taking care of the CLI stuff! I just gave it a quick spin, seems to cover all cases now and error "results" look very readable now. 💪