Consistent logging

[yhabteab]

resolves #115

[yhabteab]

@julianbrost do you still want to return wrapped errors everywhere even though they're already logged, or is it fine the way it is? And as for the HTTP response messages, Alvar has already cleaned them up with #132, so I haven't done anything in that regard here.

[julianbrost]

In general, I'd try to keep close to typical Go conventions regarding the returned errors. So that would be wrapping the errors even if we basically dismiss the message later on. Note that wrapping the error also isn't just about the message but also allows the proper use of functions like errors.Is().

[oxzi]

Maybe we could use this PR to also get rid of contractions. Currently, there is both "can't" as well as "cannot" in the code, and other contraction forms. A (most probably incomplete) grep -ri "\b[a-z]*'[a-z]*\b" also shows "doesn't", "it's", and even more.

This might not be part of the referenced issue, but fits the PR title very well.

[oxzi]

Within code - excluding comments - contractions there is still one "doesn't" in internal/filter/parser_test.go on line 144.

Otherwise, next to the two small comments, the diff looks good to me.

[oxzi]

Sorry, I have missed this typo the other time.

Otherwise, looks good to me.

[yhabteab]

Sorry! I had to adjust the time period entry a bit.

[julianbrost]

I'm surprised by the number of times where return errors.New("[...]") is replaced by just return err without wrapping it with some extra context information. Is that extra error message that was used there always redundant with what's already contained in err or in other ways pointless to add?

[yhabteab]

Is that extra error message that was used there always redundant with what's already contained in err or in other ways pointless to add?

That extra error message was supposed to be used by the listener as an HTTP response message, but since we don't want to expose such specific internal error messages to the clients, there is no need in keeping those extra error messages as they're always logged with the required additional contexts.

[julianbrost]

I don't really see the reason for rewording many of the messages. What rules are you trying to follow here or what are you trying to be consistent with? It's just a lot of places were the meaning of the messages is changed slightly and one has to check if the new message still describes what's happening. (I haven't looked at everything yet as I don't really get the point so far.)

[yhabteab]

I don't really see the reason for rewording many of the messages. What rules are you trying to follow here or what are you trying to be consistent with? It's just a lot of places were the meaning of the messages is changed slightly and one has to check if the new message still describes what's happening. (I haven't looked at everything yet as I don't really get the point so far.)

It's used to be some Icinga Web notification rule state (success/fail) -> action (started|to start) -> subject, but I've reverted all the changes now, so I don't want to wast that much time in this PR anymore.

[julianbrost]

#133 (comment):

but since we don't want to expose such specific internal error messages to the clients

#133 (review):

I'm surprised by the number of times where return errors.New("[...]") is replaced by just return err without wrapping it with some extra context information.

If you do replace these basic errors with the full internal errors, they must not be sent to the HTTP client anymore. Instead, the clients should just receive some generic "internal error, see server log".