3 ms·
You can have typed errors too. This is fairly common in Go. As long as it implements the Error interface.
by cdelsolar 10y ago
You can have typed errors too. This is fairly common in Go. As long as it implements the Error interface.
- Groxx 10y agoAt which point you're back to the original complaint of: - Should I try to catch the exception, or just let it bubble up and edit my interface to include it? - Should I create a new exception type or reuse an existing one? - Am I exposing implementation details via my interface? (eg I don't want to throw an SQLException from GenericDataSourceWidget.connect()) (except for "- Should I throw a checked or unchecked exception?" since that's fairly Java-specific) To me, those questions seem unavoidable, and sweeping them under the rug is a false simplicity. You're exposing things - what do you expose? How should the caller deal with it? Is it the same as [other thing]? I'd much rather have the type system involved, since error handling is pretty critical to correctness/stability. If go's giving up the safety, what does it get in return?
- XorNot 10y agoI feel like the type system is involved? If there's a problem it's that Go doesn't make throwing typed errors a common convention (and we lack the tooling to make handling them a habit I.e. inspect this call and find me all the error types which can come back.