I meant wrapping the lower level checked exceptions n a higher level exception. E.g. DataInputException that wraps date date format exceptions, missing entry exceptions etc. Easier for higher level functions to handle these than knowing all of the possible low level exceptions that could be thrown.
I’ve found a good rule to be to limit the throws clause to at most 3 exceptions, beyond that you need to handle/wrap in a higher level exception. I was only using fork/join as an example. In Go you still use this design - the response channel carries the request and response ( or error/exception ) - at least that is the way I would do it. You’ve also mentioned stack allocation without destructors again. Isn’t the proper way to handle this with defer (which in an exception based system would still run) or finalizers? Java routinely allocates on the stack using escape analysis and it is not an problem there. > On Jul 1, 2019, at 2:11 AM, Ian Lance Taylor <i...@golang.org> wrote: > >> 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. -- 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/F776908C-EA7F-43C0-87DA-27CE8B46855E%40ix.netcom.com. For more options, visit https://groups.google.com/d/optout.
