4 ms·

> You don't have compile time checks for errors. I don't quite understand this statement. The compiler finds errors in my code all the time. Should it be evalu

> You don't have compile time checks for errors. I don't quite understand this statement. The compiler finds errors in my code all the time. Should it be evaluating something like `if err != nil`?

metaltyphoon 4y ago
I guess what he is saying is that x, _ := someFunc() shouldn't compile if someFunc has error returns.
- H1Supreme 4y ago
  Ah, that makes sense. I wonder if a compiler flag would be a good compromise? As a way to report unhandled errors, but still let it compile.
- jerf 4y ago
  That syntax basically means "I am deliberately not handling error returns". I always pair it with a comment that explains why I can do that. It comes up. A common one for me for instance is using .Write([]byte) (int, error) on a bytes.Buffer. Because that .Write implements an interface that has an error return, there's an error return, but a byte buffer can never fail to .Write. (If it does due to memory running out, I don't think it ever comes back as an error, just the process terminating.) There's no point being more particular about it... there's no practical way to force a programmer to handle an error, especially in light of the fact that "do nothing with the error" is also a perfectly acceptable thing to do! (Example: Writing a JSON document out as the result of an HTTP API call. I don't want to log every such error, because that just crufts up my logs, I don't need metrics on this particular system, and once the HTTP stream is broken there's nowhere left to write an error out to the user, so... discard it is.)
deleted 4y ago
[deleted]
nemothekid 4y ago
A real problem is when something like this occurs x, err := thisFuncFails(); // some other lines of code, but err is not checked x.callMethod(); // this crashes at runtime unless you explicitly ignore `err`, the compiler shouldn't allow you to use `x` without checking err. In Rust/Zig this is accomplished with the union types, which doesn't allow to use `x` until you have checked it's not an error. This is also very useful for Option types; and I wish it was in Go since the beginning as having `nil` in the language is a huge mistake.
- Macha 4y ago
  The problem is worst with procedural functions os.Mkdir("foo") looks pretty innocent but with no return value to use, the compiler is no help in reminding you this is a fallible function
  - nathants 4y ago
    add errcheck and ineffassign to your build script. the compiler should really do this itself.

> You don't have compile time checks for errors. I don't quite understand this statement. The compiler finds errors in my code all the time. Should it be evaluating something like `if err != nil`?

metaltyphoon 4y ago

I guess what he is saying is that x, _ := someFunc() shouldn't compile if someFunc has error returns.

H1Supreme 4y ago
Ah, that makes sense. I wonder if a compiler flag would be a good compromise? As a way to report unhandled errors, but still let it compile.
jerf 4y ago
That syntax basically means "I am deliberately not handling error returns". I always pair it with a comment that explains why I can do that. It comes up. A common one for me for instance is using .Write([]byte) (int, error) on a bytes.Buffer. Because that .Write implements an interface that has an error return, there's an error return, but a byte buffer can never fail to .Write. (If it does due to memory running out, I don't think it ever comes back as an error, just the process terminating.) There's no point being more particular about it... there's no practical way to force a programmer to handle an error, especially in light of the fact that "do nothing with the error" is also a perfectly acceptable thing to do! (Example: Writing a JSON document out as the result of an HTTP API call. I don't want to log every such error, because that just crufts up my logs, I don't need metrics on this particular system, and once the HTTP stream is broken there's nowhere left to write an error out to the user, so... discard it is.)

deleted 4y ago

[deleted]

nemothekid 4y ago

A real problem is when something like this occurs x, err := thisFuncFails(); // some other lines of code, but err is not checked x.callMethod(); // this crashes at runtime unless you explicitly ignore `err`, the compiler shouldn't allow you to use `x` without checking err. In Rust/Zig this is accomplished with the union types, which doesn't allow to use `x` until you have checked it's not an error. This is also very useful for Option types; and I wish it was in Go since the beginning as having `nil` in the language is a huge mistake.

Macha 4y ago
The problem is worst with procedural functions os.Mkdir("foo") looks pretty innocent but with no return value to use, the compiler is no help in reminding you this is a fallible function
- nathants 4y ago
  add errcheck and ineffassign to your build script. the compiler should really do this itself.