I didn't quite get that. Sum-types is an independent issue (and can be made to
work with try!).
They seem to be using a slightly different definition of an error. They are
saying an error is when a function fails even when all its preconditions are
met. If the preconditions are not met, and the function fails to perform, it is
not an error but something else.
I tend to think the distinction is not very useful. If a function fails to
perform in spite of all preconditions being met, it is either a runtime
hardware error or a bug. Even in this case one can recover but the cost may be
high. Think of triple redundancy or just shipping off partial state to another
machine (provided you have checkpointed) or any number of other things. It used
to be that if a disk read failed a program had to fail but then we got RAID and
ZFS etc. It all depends on context and available technology and cost.
I also tend to think things won't be very different in 10 years. There have
been papers going back 40-50 years that talk about systematic error handling
and recovery. There was this idea of "recovery blocks" where you use a fast
algorithm that works correctly in most of the cases but if it fails (and you
need checking software for it), you give the same problem to an alternate but
slow code. Great idea but a) this is expensive and b) may not be possible in
general.
> On Jul 11, 2019, at 9:35 PM, Andrey Tcherepanov
> <xnow4fippy...@sneakemail.com> wrote:
>
> 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
>
> <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
> <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
> <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
> <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
> > <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
> >
> > <https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWZEg091q2Z2bmNrbgewOPH-TMGnoc1hB4V44tMtGyzuw%40mail.gmail.com>.
> >
> > For more options, visit https://groups.google.com/d/optout
> > <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
> <mailto: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
>
> <https://groups.google.com/d/msgid/golang-nuts/20e08321-1c95-4663-a94e-604f62f838ac%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout
> <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/E632FABC-B1F1-4CD5-8E9A-4F658357838F%40bitblocks.com.
For more options, visit https://groups.google.com/d/optout.
