I consider checked vs unchecked exceptions “well written” or even valid code. Checked exceptions are similar to Gos error return except more/easier/better? compile and coding time validation. Unchecked exceptions are similar to panic recover except you have more information.
There is no difference between checked exceptions and Go’s error return in terms of responsibility - but exceptions are more easily enforced. When it comes to unchecked exceptions a lot depends on the use case. For instance, the consider an illegal state exception. Clearly a programming error, but how it is handled at higher levels depends... maybe roll back the current transaction and report an error to the caller, maybe crash the server? It all depends on the context , risk, capabilities - easier for higher layer to make this call than a low level function. Coupled with RAI you can create very robust and reliable systems. > On Feb 20, 2021, at 2:30 PM, Ian Lance Taylor <i...@golang.org> wrote: > > On Sat, Feb 20, 2021 at 12:11 PM Robert Engels <reng...@ix.netcom.com> wrote: >> >> Can you clarify what you mean mean by “the code does exactly what it shows >> on the page”? How do you know by looking at the code, or even compiling the >> code, that all possible errors returned by a function are handled? That to >> me is biggest difficult in reading (or using) others Go code. Exceptions >> (well written) handle this by declaring all possible error (or categories) >> thrown by the method. >> >> This seems a real problem with long term maintenance of Go code. > > When you say that exceptions means declaring all possible errors > thrown by the method, it seems to me that you are talking about > checked exceptions. There is pretty good evidence that real programs > in practice do not list all possible error categories, even though > ideally they should. Instead, in practice, they fall back to > unchecked exceptions. > > So I think that your contrast to Go is an ideal that experience has > shown is very difficult to achieve. It's not an approach that leads > to better long term maintenance in practice, even if it should in an > ideal world. > > (Incidentally, to answer the question in your first sentence directly, > Go code does indeed do exactly what it shows on the page. You are > challenging that not by saying that it does something else, but by > saying that that is not enough.) > > Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/D5D376CE-34D2-4575-94F4-CF899545F368%40ix.netcom.com.
