I’ve developed systems that wrap checked exceptions in unchecked ones, but in every case I can think of it was to “abort to the top” - returning control (or exiting) - it is a specialized case of the re-throw, but I would argue it is rarely used in anything other than framework type code, with applications code typically wrapping the specific exception in an “higher-level application checked exception”, that the upper layers handle (possibly inspecting the “cause” exception.
As to not answering the question about transferring across Go routines, I apologize. It was not intentional - I read the statement a few times and didn’t quite get the concern - and meant to get back to it and forgot - but I read it again a few times and still don’t understand the problem. What is particular about Go that makes this difficult? It is pretty common practice to pass exceptions across threads in Java and C++ - e.g. fork/join and the worker thread throws an exception - the exception is passed to the joining thread. Conceptually, it is as if the function was called serially and the exception thrown at the fork point. In these cases the exception is wrapped, but it has to be because of the strong type system. It is also pretty trivial to declare a wrapper function that declares the checked exceptions for clarity - this is done routinely in rpc using proxies. > On Jun 30, 2019, at 8:43 PM, Ian Lance Taylor <i...@golang.org> wrote: > > On Sun, Jun 30, 2019 at 5:23 PM robert engels <reng...@ix.netcom.com> wrote: >> >> I am going to disagree here. I don’t think ‘checked exceptions’ exhibit this >> behavior. Addressing the points from the Joeal article, > > Checked exceptions address some of the difficulties with exceptions. > However, they introduce new difficulties, and I do not believe they > work in large-scale programs. In practice, checked exceptions > degenerate into unchecked exceptions. Changing the set of exceptions > that a function throws forces all callers to adjust their set of > exceptions. In practice this is so painful that programs catch > exceptions and turn into them into unchecked exceptions. There are a > number of discussions on the Interwebs about the problems with checked > exceptions; here's one: https://www.artima.com/intv/handcuffs.html . > > I note that you didn't reply to my comment about passing errors across > 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/CAOyqgcWZEg091q2Z2bmNrbgewOPH-TMGnoc1hB4V44tMtGyzuw%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/BAD8DE0B-3A77-415D-B8D8-D376E74636B7%40ix.netcom.com. For more options, visit https://groups.google.com/d/optout.
