[Answering here to @applepearlime bc limits of my green acct]
They do have firebreaks, paths for trucks to go in many places [1]. I've seen many.
But you could argue they're not wide enough to actually break fire. And when I see videos of how tall and wide the flames are, I have no idea how wide they should be... It's a managed forest though, definitely looked after because economics interests (wood, tourism).
I grew up there. I used to bike along stretches of firebreaks between plots. These firebreaks are nowhere nearly enough. Trees are young, pine needles spread everywhere, and ground is sandy.
You used "_" to ignore the error variable, which I call "IDGAF" placeholder.
So, you willingly ignored the error and tell me that you don't have to check the error? You told the compiler that you don't care about the error explicitly (via "_"). That's on you then.
In my first comment I noted in the P.S. section:
...if you ignore the error, this is a deliberate choice and the burden is on the developer.
You used "_" knowingly. Compiler/linter didn't add it there by itself.
I mean, do you even read the language documents to understand how a language works?
Are you really being so obtuse? Of course in real code you might use the error. For printing, forwarding it to a logging frame or anything else. The point is the error does not guard access to the return value. Here basically the same example:
package main
import (
"errors"
"fmt"
)
func getMessage() (string, error) {
return "DO NOT INSPECT", errors.New("something went wrong")
}
I am skeptical about Go's error handling, but there are cases where it is desirable to return both a result and also an error, like returning what can be returned while warning users about any errors. That can be modeled in Rust and other languages as well, though it is the default for Go.
Are you sure?
https://en.wikipedia.org/wiki/1949_Landes_forest_fire