Hacker News Reader

Comment by tsimionescu | Hacker News Reader

The whole DomainError thing only makes sense if you expect someone to handle this error (and by handle, I mean doing something other than logging and aborting some operation), or if you are writing a very generic library. Otherwise, it is wasted time and extra complexity that makes the code harder to read.

View on HN

It depends on how much context is needed. Imagine you have a Go library that parses JavaScript. Parsing can return an error, and it's very helpful to know information like the line and column number. So you might have an error like this:

    type ParseError struct {
        Line int
        Col  int
        Message string
    }

The user of your library isn't expected to handle this error explicitly, but when they print the output, they can see exactly where the issue was.

Do you expect any piece of code to touch err.Line and err.Col? I definitely don't - I would expect the line and col to be included in the message of a basic string error.

Yes, that's true, just as it is with exceptions in the original article. However, if you are writing the code and it's callers, if you don't want to handle the error, why even have it? Just log the results there and move on.

> However, if you are writing the code and it's callers, if you don't want to handle the error, why even have it? Just log the results there and move on.

Well at very least you need the caller to know that the operation didn't succeed. And if the failure is deep in the call stack, you may not have enough information to log a meaningful error. Returning errors and wrapping them with a description as you pass them up the stack means you can have a single meaningful log message at the "top level" (wherever the buck stops).

Reply on news.ycombinator.com