I am going to disagree here. I don’t think ‘checked exceptions’ exhibit this behavior. Addressing the points from the Joeal article,
Point#1 "They are invisible in the source code. Looking at a block of code, including functions which may or may not throw exceptions, there is no way to see which exceptions might be thrown and from where. This means that even careful code inspection doesn’t reveal potential bugs.” This is not true. It is a limitation of the editor. There are IDEs that will annotate every line with the exceptions possibly thrown by the function call - it is part of the function signature. The compiler will also clearly complain if a checked exception is not handled or re-thrown. The information is there, and it is certainly better than having to read documentation (which may not be correct) in the Go case. In the Go case, all the compiler knows is that either no return values or all return values must be captured (including their types), with nothing about possible error values, so how is the developer supposed to handle them - I don’t see how that is an improvement. The exception signature is far more powerful and self-documenting. Point #2: "They create too many possible exit points for a function. To write correct code, you really have to think about every possible code path through your function. Every time you call a function that can raise an exception and don’t catch it on the spot, you create opportunities for surprise bugs caused by functions that terminated abruptly, leaving data in an inconsistent state, or other code paths that you didn’t think about." This is not true as well. It is common understanding when working with exceptions, that there are 3 typical outcomes: 1. retry 2. re-throw 3. log and return from function. The catch and log and continue is an anti-pattern used by inexperienced developers. Granted, much of exception handling is simplified in the case of GC environment, and finalizers for other resources, but the latter can be too lazy, and thus try-with-resource which completely handles the inconsistent state aspect of Point #2. Furthermore, the ‘think about every possible code path through your function” is pretty much nonsense. A developer does this every time they write a loop, or any other control structure. If anything, checked exceptions force the developer to think even deeper about handling errors, which a Go should be doing too (but can even ignore more easily). Like I said, I think Go error handling is fine for C size applications, it breaks down quickly in large applications that must be resilient, mainly when attempting to incorporate library (internal or external code). For small applications developers will use if err!= nil panic(err) > On Jun 30, 2019, at 6:09 PM, Ian Lance Taylor <i...@golang.org> wrote: > > On Sun, Jun 30, 2019 at 4:16 AM robert engels <reng...@ix.netcom.com> wrote: >> >> I am not sure the ‘unexpected flow control’ concern is of the same >> importance as when this statement was first written, given paradigms like >> ‘reactive programming’ (I don’t like it, but it seems most others are not >> bothered by it). >> >> I am curious more though in the belief that exceptions are unexpected flow >> control. At least with caught exceptions, this is not the case IMO. You know >> the exact point at which the exceptions can occur - this is part of the >> beauty of exceptions in that the code is self documenting to a higher degree >> and can be subject to automated analysis far more easily >> (https://arxiv.org/pdf/1708.00817.pdf) In principle, every error in Go >> should be handled, but the compiler does not enforce this. I also think that >> try-with-resource solves many of the life-cycle concerns very elegantly >> (whether you like Java or not, a lot can be learned from the evolution the >> language). Still caught exceptions cause problems with functional methods >> (and so does error return), although I’m not a big fan of functional either >> (for lack of readability). > > The unexpected flow of control when using exceptions is not at the > point where the exception is thrown, nor at the point where the > exception is caught. It is the functions in between that point. When > exceptions are used routinely, every single function call is a > possible change in flow of control. > > That is of course true in Go today because any function may call > panic, but we we can cope with that in practice because calling is > panic is discouraged and rare, especially if an unrecovered panic > crosses a package boundary. But errors must be routinely returned > across package boundaries, so if we use exceptions to handle errors > then we inevitably have unexpected flow of control. > > This is hardly a novel view, of course. E.g., > https://www.joelonsoftware.com/2003/10/13/13/ . > > And since Go programs routinely require transferring an error between > one goroutine and another, in Go we would have to have to some clean > and simple way to transfer an exception between goroutines. > > 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/CAOyqgcVJiXjVbxRCidDrN7hfwiftqs280on2fuwypPphJqpC1g%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- 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/3912F62D-9537-43F2-A763-B1609A5A1F8C%40ix.netcom.com. For more options, visit https://groups.google.com/d/optout.
