Thank you very much for pointing to that paper! Somehow I think it will be
referenced in the future with a prefix "seminal" :)
What these guys are proposing in that paper would be closer to (Go-style)
func f() (v value | e error) { ... }
(where "|" could be read as "or" or "union")
with that in mind , the call to f might be something like
v := f()
if e := v.(error) {
...
}
A.
On Monday, July 1, 2019 at 12:46:29 AM UTC-6, Sanjay wrote:
>
> 3 of the most well-known new languages in the past decade (Swift, Rust,
> and Go, respectively) have all eschewed exceptions for control flow in
> favor of some sigil in the source code to propagate errors explicitly.
> Swift uses try-statements (along with a few other control flow constructs),
> Rust uses the "?" operator (previously the try! macro), and Go uses "if err
> != nil".
>
> C++, a language which does have exceptions, has significant fractions of
> its user base which disable exception support entirely (20% according to a
> survey) or partially (52%). Google, for instance, almost invariably
> compiles with -fno-exceptions and uses macros to propagate errors
> explicitly (see
> https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/stubs/status_macros.h#L49
> to
> get a sense for how that works). Herb Sutter, one of the well-known members
> of the C++ standards committee from Microsoft, has proposals out to make
> propagating exceptions require a visible sigil in the source code (also a
> "try" expression, FWIW): https://youtu.be/os7cqJ5qlzo?t=2939 (an
> interesting talk overall, I've linked to the specific relevant time). His
> actual proposal paper is also an interesting read:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0709r3.pdf. In a
> table with the following introduction "This section lays out what I believe
> are ideal error handling characteristics. They are not unique to C++; I
> believe they apply to most modern languages", he lists "Unhandled error
> propagation is visible" as something not provided by C++ exceptions today.
>
> It's possible that a decade from now, this will all have been a minor
> blip, and you will eventually be proven right. But at the very least, this
> context that should inform your priors.
>
> Sanjay
>
> PS - checked exceptions don't really have a great leg to stand on either
> (e.g. consider their interaction with Java 8's streams:
> https://www.oreilly.com/ideas/handling-checked-exceptions-in-java-streams,
> or consider that both Scala and Kotlin don't implement support for them at
> all)
>
> On Sunday, June 30, 2019 at 7:34:54 PM UTC-7, robert engels 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.
>>
>> 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 <ia...@golang.org>
>> wrote:
>> >
>> > On Sun, Jun 30, 2019 at 5:23 PM robert engels <ren...@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 golan...@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/20e08321-1c95-4663-a94e-604f62f838ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
