@movq@www.uninformativ.de I used to be intimidated by FFmpeg, but since I’ve been digging deeper into the options I’m having a lot of fun.

@abucci@anthony.buc.ci I’ve never tried Caddy. Nginx does what I need it to do, most of the time. I also use darkhttpd for testing.

@mckinley@twtxt.net Haha, while composing I was wondering two or three times whether I should throw my thoughts in an HTML page instead. But out of utter laziness I discarded that idea. ¯_(ツ)_/¯

@prologic@twtxt.net Yes, that’s him. It’s the 4th anniversary of his death.

We’ve barreled past the microblog line and flew straight over the e-mail chain line. This is just social blogging.

@abucci@anthony.buc.ci Writing Python and Makefiles, I actually never have any trouble there. All my editors are configured properly.

The fundamental error was to enable people making tabs arbitrarily wide. :-)

@abucci@anthony.buc.ci Yup. Just send them a merge request with a fix. :-)

Now, looking at @xuu@txt.sour.is’s es, I feel quite a bit stupid. In my particular case I could have just put the %w at the front of the message and not at the end and get exactly what I want: fmt.Errorf("%w '%s'", ErrInvalidSentBytes, sentBytes) results in “invalid sent bytes ‘4385743057573509732574375098741128354092547569201274123’” and can be error.Is(err, ErrInvalidSentBytes-asserted. No idea why I did not think of that. O_o Thanks mate! :-)

@prologic@twtxt.net In one project a bunch of work mates strongly advocated a new to everyone (them included) idea. Any incoming request must produce exactly one log line. Not more and not less. Exactly one. That way the log does not get spammed with lots of useless information most of the time and one immediately sees what went wrong, if at all. In the beginning I thought this is completely rediculous, because I had never seen this anywhere and thus just couldn’t imagine that this will work at all.

The technical details to only produce one log per request were sorted out fairly quickly with a customer logger, that just replaces the last message with the newly logged one and finally at response end actually logs it. When a Java component was completely rewritten in Go they tried it out and I was very surprised that it worked that well for the analysis. I basically never missed any other surrounding logs that would have been produced in the old log flooding style. Over time a few things such as structured context fields were added that turned out to be useful to have for error analysis. It’s been a couple of years, but I think we rewrote that logger a bunch of times to optimize even further and try out new API ideas we had.

I remember it as a surprisingly successful experiment. In my current project I also once tried to tell my work mates about that, but – just like me when I heard about it in the first month – they weren’t ready for it. :-) To be fair, we have a slightly different situation now than in the other project.

@prologic@twtxt.net Error handling especially in Go is very tricky I think. Even though the idea is simple, it’s fairly hard to actually implement and use in a meaningful way in my opinion. All this error wrapping or the lack of it and checking whether some specific error occurred is a mess. errors.As(…) just doesn’t feel natural. errors.Is(…) only just. I mainly avoided it. Yesterday evening I actually researched a bit about that and found this article on errors with Go 1.13. It shed a little bit of light, but I still have a long way to go, I reckon.

We tried several things but haven’t found the holy grail. Currently, we have a mix of different styles, but nothing feels really right. And having plenty of different approaches also doesn’t help, that’s right. I agree, error messages often end up getting wrapped way too much with useless information. We haven’t found a solution yet. We just noticed that it kind of depends on the exact circumstances, sometimes the caller should add more information, sometimes it’s better if the callee already includes what it was supposed to do.

To experiment and get a feel for yesterday’s research results I tried myself on the combined log parser and how to signal three different errors. I’m not happy with it. Any feedback is highly appreciated. The idea is to let the caller check (not implemented yet) whether a specific error occurred. That means I have to define some dedicated errors upfront (ErrInvalidFormat, ErrInvalidStatusCode, ErrInvalidSentBytes) that can be used in the err == ErrInvalidFormat or probably more correct errors.Is(err, ErrInvalidFormat) check at the caller.

All three errors define separate error categories and are created using errors.New(…). But for the invalid status code and invalid sent bytes cases I want to include more detail, the actual invalid number that is. Since these errors are already predefined, I cannot add this dynamic information to them. So I would need to wrap them à la fmt.Errorf("invalid sent bytes '%s': %w", sentBytes, ErrInvalidSentBytes"). Yet, the ErrInvalidSentBytes is wrapped and can be asserted later on using errors.Is(err, ErrInvalidSentBytes), but the big problem is that the message is repeated. I don’t want that!

Having a Python and Java background, exception hierarchies are a well understood concept I’m trying to use here. While typing this long message it occurs to me that this is probably the issue here. Anyways, I thought, I just create a ParseError type, that can hold a custom message and some causing error (one of the three ErrInvalid* above). The custom message is then returned at Error() and the wrapped cause will be matched in Is(…). I then just return a ParseError{fmt.Sprintf("invalid sent bytes '%s'", sentBytes), ErrInvalidSentBytes}, but that looks super weird.

I probably need to scrap the “parent error” ParseError and make all three “suberrors” three dedicated error types implementing Error() string methods where I create a useful error messages. Then the caller probably could just errors.Is(err, InvalidSentBytesError{}). But creating an instance of the InvalidSentBytesError type only to check for such an error category just does feel wrong to me. However, it might be the way to do this. I don’t know. To be tried. Opinions, anyone? Implementing a whole new type is some effort, that I want to avoid.

Alternatively just one ParseError containing an error kind enumeration for InvalidFormat and friends could be used. Also seen that pattern before. But that would then require the much more verbose var parseError ParseError; if errors.As(err, &parseError) && parseError.Kind == InvalidSentBytes { … } or something like that. Far from elegant in my eyes.