On Sun, Jun 30, 2019 at 7:34 PM robert engels <reng...@ix.netcom.com> wrote: > > 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.
Sure, but as soon as you've wrapped a checked exception you've lost the advantage of checked exceptions, and gone back to having to worry about control flow at every function call. Which, again, is a significant issue in a language like Go that uses stack allocation but does not have destructors. > 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. Go doesn't have join. Think about how you would write a basic Go construct like https://godoc.org/golang.org/x/sync/errgroup if errors are handled via exceptions. I'm not saying you can't do it--of course you can do it. But it seems to me that it would require a bunch of awkward boilerplate that would be easy to get wrong. 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/CAOyqgcVN6hEJKX0F9PikVvfo2w9fT9EUD7HqOzTCmN5ce5GNNA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
