Ok but exceptions also give you alot of context about the error like exactly where it occured. How is that handled in Go?
type ParseError struct {
line int
}
func (e ParseError) Error() string {
return "Parse error at line: " + fmt.Sprint(e.line)
}
Note: The current release may vary slightly on the details. I'm using a pre-release build. But older versions are similar. switch err.(type) {
case db.IOError:
// Database exception here
case io.FileNotFoundError:
// File exception
default:
// Pass it to our caller for them to handle.
return nil, err
}
Which gives you the ability to selectively catch errors based on type.I think too many people get wrong idea about exceptions from defaults in many environments. Exceptions being thrown should not normally be a sign of a bug; knowing the line number the exception thrown should be irrelevant information almost all the time, save for errors like access violations or null pointer exceptions.
Instead, the information contained in an exception can usually be turned into actionable data to a user or administrator of an app (depending on whether it's on the client or server).