3 ms·

Unless you put the function name somewhere in the error, there is no way to know where something happened. "Some thing didn't write properly? Cool! Where and wh

Unless you put the function name somewhere in the error, there is no way to know where something happened. "Some thing didn't write properly? Cool! Where and which line?"

dannymi 4y ago
If it's an internal (unexpected) error, panic. You get a backtrace and everything--which helps because it was an unexpected internal error, so you probably messed up. You'd like to know where that is. But if it's an actual user-visible error code then that means you expected for this error to happen eventually and you designed for it. Why then do you need a backtrace? You program is doing what it's supposed to. I mean sure while developing it's nice to be able to just replace the error code emission by panic (which I do sometimes)--but in regular operation? It doesn't help the user at all.
klodolph 4y ago
> "Some thing didn't write properly? Cool! Where and which line?" My eyes glaze over when I'm trying to read stack traces in Java or Python, and then it turns out I can't figure out what's wrong because the stack trace doesn't include the path of the file that failed to parse. What we care about is stuff like: - Program tried to parse file X, - Failed because file X doesn't exist, or because file contains syntax errors, or something - Some context giving us the reason why program tried to read file X, which is usually at a fairly high level (something like "could not load config"). Putting the function name in the error-handling code is something that you SOMETIMES do, but only when it adds important context. If you do it all the time you end up with something completely unreadable, like a stack trace. There are various libraries you can use that give you stack traces for errors in Go, if that's what you want. If I get an error that X is not a valid JSON file--often, that's all I need to know, because I can open X and see the syntax error and fix it. Knowing the name of the function that detected the syntax error is unhelpful, usually, and we have logging + debuggers to help with those cases.
- lenkite 4y ago
  Java stack-traces are extraordinarily informative - they give line number, class, method and even offset inside relative lambda when an exception occurs. Few languages do better and Go is not one of them.

Unless you put the function name somewhere in the error, there is no way to know where something happened. "Some thing didn't write properly? Cool! Where and which line?"

dannymi 4y ago

If it's an internal (unexpected) error, panic. You get a backtrace and everything--which helps because it was an unexpected internal error, so you probably messed up. You'd like to know where that is. But if it's an actual user-visible error code then that means you expected for this error to happen eventually and you designed for it. Why then do you need a backtrace? You program is doing what it's supposed to. I mean sure while developing it's nice to be able to just replace the error code emission by panic (which I do sometimes)--but in regular operation? It doesn't help the user at all.

klodolph 4y ago

> "Some thing didn't write properly? Cool! Where and which line?" My eyes glaze over when I'm trying to read stack traces in Java or Python, and then it turns out I can't figure out what's wrong because the stack trace doesn't include the path of the file that failed to parse. What we care about is stuff like: - Program tried to parse file X, - Failed because file X doesn't exist, or because file contains syntax errors, or something - Some context giving us the reason why program tried to read file X, which is usually at a fairly high level (something like "could not load config"). Putting the function name in the error-handling code is something that you SOMETIMES do, but only when it adds important context. If you do it all the time you end up with something completely unreadable, like a stack trace. There are various libraries you can use that give you stack traces for errors in Go, if that's what you want. If I get an error that X is not a valid JSON file--often, that's all I need to know, because I can open X and see the syntax error and fix it. Knowing the name of the function that detected the syntax error is unhelpful, usually, and we have logging + debuggers to help with those cases.

lenkite 4y ago
Java stack-traces are extraordinarily informative - they give line number, class, method and even offset inside relative lambda when an exception occurs. Few languages do better and Go is not one of them.