Just one other important point, I think the Go documentation makes the case for
exceptions. If you read the blog post https://blog.golang.org/errors-are-values
you’ll see this suggested code cited as a “better way”:
scanner := bufio.NewScanner(input)
for scanner.Scan() {
token := scanner.Text()
// process token
}
if err := scanner.Err(); err != nil {
// process the error
}
so in this case, not only do you not check errors on the scanner.Scan(), you
have to possess deeper knowledge of the API to know that scanner.Err() needs to
be called (and checked) post processing.
Imagine doing code reviews of a large code base where this technique was used
extensively - you would need to have every internal and external API memorized.
Contrast this with scanner.Scan() throwing a caught exception - it either must
be caught there or propagated - self documenting for the code reviewer.
> On Jun 30, 2019, at 6:16 AM, robert engels <reng...@ix.netcom.com> wrote:
>
> I am not sure the ‘unexpected flow control’ concern is of the same importance
> as when this statement was first written, given paradigms like ‘reactive
> programming’ (I don’t like it, but it seems most others are not bothered by
> it).
>
> I am curious more though in the belief that exceptions are unexpected flow
> control. At least with caught exceptions, this is not the case IMO. You know
> the exact point at which the exceptions can occur - this is part of the
> beauty of exceptions in that the code is self documenting to a higher degree
> and can be subject to automated analysis far more easily
> (https://arxiv.org/pdf/1708.00817.pdf) In principle, every error in Go should
> be handled, but the compiler does not enforce this. I also think that
> try-with-resource solves many of the life-cycle concerns very elegantly
> (whether you like Java or not, a lot can be learned from the evolution the
> language). Still caught exceptions cause problems with functional methods
> (and so does error return), although I’m not a big fan of functional either
> (for lack of readability).
>
> Personally, and I’ve stated it before, but I’ll go on record again, I
> wouldn’t change Go’s error handling at this point. I don’t think the sweet
> spot for Go applications requires it, and the difference in mixed code-bases
> would make things worse not better (e.g. exception based code calling error
> return based code).
>
> But if I were to expand the scope, I would make breaking changes in Go2 (so
> no mixing of methodology) for both error handling, and generics, and probably
> a few other things, without regards to backwards compatibility. Go is
> definitely a better C, but C is a systems language, not a large scale
> application language. There’s a possibility that Go could be both a great
> systems language and a great applications language, but I’m doubtful as the
> concerns are too distinct.
>
>> On Jun 30, 2019, at 12:05 AM, Ian Lance Taylor <i...@golang.org> wrote:
>>
>> On Sat, Jun 29, 2019 at 12:45 PM Robert Engels <reng...@ix.netcom.com> wrote:
>>>
>>> If you don’t understand the history you are doomed to repeat it. The ‘try’
>>> proposal is barely better than the current situation. There is as a reason
>>> exception handling with try catch was designed along with OO. It simplifies
>>> error handling immensely. “Try” as you might, you might think you are
>>> improving on it, but you’re not.
>>>
>>> Go should implement caught exceptions and be done with it. Stop trying to
>>> be cute. Take what works elsewhere and stop thinking you’re always the
>>> smartest person in the room.
>>
>> I think that https://golang.org/doc/faq#exceptions is still true.
>>
>> One of the commonly mentioned objections to the "try" proposal is that
>> the try function causes a change in flow of control without clearly
>> signaling that. In a language where exceptions are thrown to handle
>> errors, unexpected flow of control is routine. Go does support
>> exceptions in the form of the panic and recover functions, but they
>> are stylistically discouraged, so few people use them for error
>> handling. Experience has shown that unexpected flow of control from
>> exceptions makes it harder to write correct programs. That is even
>> more true in a language Go which allocates objects on the stack but
>> does not have destructors.
>>
>> 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/10DCB915-FB30-4F9A-9AFA-E36759269F94%40ix.netcom.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/52010C3B-2719-450D-8FD7-33AC6E3457CC%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.
