5 ms·

>Rolling your own error library is trivial. And right there is where you’re going to lose most people. If it’s is trivial, why isn’t in the standard library?

>Rolling your own error library is trivial. And right there is where you’re going to lose most people. If it’s is trivial, why isn’t in the standard library? If everyone needs to do it, why not standardize? I love Go, but i have to agree with grandparent poster.

cpuguy83 7y ago
You can't standardize until people agree. The trivial part isn't the code it's what is acceptable to everyone. If people don't agree then it by definition does not belong in the stdlib.
- TheDong 7y ago
  People disagreeing is even more the reason to standardize for things that matter to the broad ecosystem. For example, no one likes gofmt (tabs, eww), but everyone likes code across packages looking the same. And so we use it.
  - cpuguy83 7y ago
    and gofmt existed before go really had a large community. It's also a very different problem because you can change formatting decisions from one version to another (and they do!), but API's are difficult to change.
  - Vendan 7y ago
    Speak for yourself, Go is a bastion of formatting sanity for me cause they chose (correctly) to use tabs. Tabs for indentation are the obvious choice to improve code readability and accessibility for people that want different indent sizes. I don't need it (usually), but I've met people that prefer everything from 2, 4 or 8 spaces, and have heard of people wanting everything from 1 to 8. It also handles far more sanely then spaces for people using proportional fonts instead of monospace, another common readability/accessibility tweak.
- cpuguy83 7y ago
  *the hard part isn't the code I guess I finished that sentence in a different way than I started it.
earthboundkid 7y ago
Because everyone needs something different and failure is your domain: https://middlemost.com/failure-is-your-domain/ https://middlemost.com/failure-is-your-domain/
omegabravo 7y ago
> If it’s is trivial, why isn’t in the standard library Getting a stack trace is available in the runtime/debug library. Perhaps stack traces aren't in normal errors since a program can throw 1,000 errors per second in a perfectly functioning application and that could get expensive. I have heard that performance is the reason but I'm not able to confirm that. github.com/pkg/errors is fairly ubiquitous and includes stack traces. > If everyone needs to do it, why not standardize The only time I've needed to read the stack trace in go, is when there has been an unexpected panic. Otherwise my error messages are more than sufficient to find the root cause of the error. I only have to run my own code though, I imagine if I was debugging someone elses code the stacktrace would be invaluable. Go has purposely tried to do a few things differently. Date format comes to mind, and lack of exceptions which I personally like.
delusional 7y ago
> If it’s is trivial, why isn’t in the standard library? Trivial does not mean generic. Just because error handling is easy doesn't mean I want the same handling as you do.
- wst_ 7y ago
  Somehow I don't buy it. If you don't want rich standard for error handling, nothing prevents you from returning just a string as an error. It's just a value, isn't it? Error handling is generic by itself. This is at the heart of any existing application. It is fundamental part of the design process and later on contributes greatly to troubleshooting. Making this solid should be, IMHO, one of the most important and thought through part of any language. In Go it seems to be left at the developer's convenience. And even though you may say there is a huge debate on the subject, it always leads to nothing. Or almost nothing, like in this case. It's just disappointing.

cpuguy83 7y ago

You can't standardize until people agree. The trivial part isn't the code it's what is acceptable to everyone. If people don't agree then it by definition does not belong in the stdlib.

TheDong 7y ago
People disagreeing is even more the reason to standardize for things that matter to the broad ecosystem. For example, no one likes gofmt (tabs, eww), but everyone likes code across packages looking the same. And so we use it.
- cpuguy83 7y ago
  and gofmt existed before go really had a large community. It's also a very different problem because you can change formatting decisions from one version to another (and they do!), but API's are difficult to change.
- Vendan 7y ago
  Speak for yourself, Go is a bastion of formatting sanity for me cause they chose (correctly) to use tabs. Tabs for indentation are the obvious choice to improve code readability and accessibility for people that want different indent sizes. I don't need it (usually), but I've met people that prefer everything from 2, 4 or 8 spaces, and have heard of people wanting everything from 1 to 8. It also handles far more sanely then spaces for people using proportional fonts instead of monospace, another common readability/accessibility tweak.
cpuguy83 7y ago
*the hard part isn't the code I guess I finished that sentence in a different way than I started it.

earthboundkid 7y ago

Because everyone needs something different and failure is your domain: https://middlemost.com/failure-is-your-domain/ https://middlemost.com/failure-is-your-domain/

omegabravo 7y ago

> If it’s is trivial, why isn’t in the standard library Getting a stack trace is available in the runtime/debug library. Perhaps stack traces aren't in normal errors since a program can throw 1,000 errors per second in a perfectly functioning application and that could get expensive. I have heard that performance is the reason but I'm not able to confirm that. github.com/pkg/errors is fairly ubiquitous and includes stack traces. > If everyone needs to do it, why not standardize The only time I've needed to read the stack trace in go, is when there has been an unexpected panic. Otherwise my error messages are more than sufficient to find the root cause of the error. I only have to run my own code though, I imagine if I was debugging someone elses code the stacktrace would be invaluable. Go has purposely tried to do a few things differently. Date format comes to mind, and lack of exceptions which I personally like.

delusional 7y ago

> If it’s is trivial, why isn’t in the standard library? Trivial does not mean generic. Just because error handling is easy doesn't mean I want the same handling as you do.

wst_ 7y ago
Somehow I don't buy it. If you don't want rich standard for error handling, nothing prevents you from returning just a string as an error. It's just a value, isn't it? Error handling is generic by itself. This is at the heart of any existing application. It is fundamental part of the design process and later on contributes greatly to troubleshooting. Making this solid should be, IMHO, one of the most important and thought through part of any language. In Go it seems to be left at the developer's convenience. And even though you may say there is a huge debate on the subject, it always leads to nothing. Or almost nothing, like in this case. It's just disappointing.