But - the issue is that most of the time - for complex systems - the errors
cannot be handled where they are encountered - even in Go, most of the error
handling becomes boilerplate returning the error detected and expecting some
higher level to handle it.
With exceptions this is enforced, or at least codified, and with GC/RAI the
system with try/finally can have a coherent view of the current state. You can
do this with Go, but it is not “easy” by any means. Exceptions force the error
handling up the stack until the layer is capable of handling it.
Go - whether people like this or not - is VERY close to Java (because of the
“runtime”) - and both suffer from “runtime overhead/startup cost” - so Go
processes become “servers”. Writing resilient user space servers is difficult
in Java and more so in Go due to the lack of exceptions.
Beyond error handling, Go (and Java) are weak in resource management - which
opens another door of bugs/problems related to “user space OS”.
Every OS has exceptions - i.e. process failure due to unforeseen reasons.
There are other tactical problems that exceptions solve that error returns do
not. Think of a complex multi-component system - and a module decides to expose
a new “class of errors” - with exceptions you can force existing well-written
code to break at compile time (unknown exception in the hierarchy), with error
returns this is not possible (at least not in Go with non-standardized error
“classes”). Any there are many similar problems.
These are all issues C programmers struggled with for years - and why error
handling was changed in C++.
> On Feb 17, 2021, at 9:42 PM, Henry <henry.adisuma...@gmail.com> wrote:
>
> I actually prefer the explicit error handling:
> ```
> f, err := os.Open("path")
> if err != nil {
> //handle error
> }
> ```
> When you are reading the code to look whether a certain condition has been
> handled, the explicit branching statement makes it easier to scan.
> On Wednesday, February 17, 2021 at 1:46:07 AM UTC+7 skinne...@gmail.com
> <http://gmail.com/> wrote:
> I wanted to express my thanks to Mickael McKinnus for his research.
>
> I am someone who is quite happy with the error handling in Go as it lets me
> implement whatever I like, I must say it is obviously flawed from the
> standpoint that the proper constructs are not part of the language but part
> of our training. The discreet patterns I use are:
> Handle errors that can be handled close to where they occur.
> Report errors that cannot be handled because they were caused by the calling
> function passing a bad parameter.
> Panic on errors that prevent a function that MustComplete from completing
> because they cannot be handled.
> Try a MustComplete() with recover from the panic that reports to the User and
> or Developer the nature of the problem and how to resolve it manually or at
> least add it to issues.
> Ensure that no matter what happens, you do not corrupt the HDD, lockup the
> hardware, CTD, or leave unexpected artefacts on the screen.
> There is no one best way of dealing with errors but there are patterns for
> dealing with errors, if you only learn one pattern then you will not be
> writing good code (if you only have a hammer, everything looks like a nail).
>
> Golang does not have error patterns that are clear and distinct for novice
> programmers and it does not inhibit advanced programmers from dealing with
> errors in whatever way they think appropriate.
>
> A useful abstraction would be to simplify the error handling by
> identification of the type of pattern desired and use the most concise and
> yet easily understood way of writing it. Go has tools in place to allow each
> user to create a preprocessor for error handling or any other purpose but it
> would be nice if we were all on the same page.
>
> On Monday, February 15, 2021 at 12:53:43 PM UTC-6 ren...@ix.netcom.com
> <applewebdata://3A7FDC87-B992-4601-8DA2-ED122459CC8D> wrote:
> And I will tell you that after working with error returns and exceptions,
> exceptions are superior - but much depends on the complexity of the system.
> For small system level tools that are pieced together via pipes, C error
> handling is fine - because the process serves as the exception handling
> point. For complex server long-lived processes, exception handling makes it
> much easier to design and deliver secure fault tolerant systems. Resilient
> Unix relies on the ability to start new processes to handle requests, track
> DoS attacks, faulty clients, etc. Process termination is a part of this. The
> Go runtime does not fit this model, so it needs to replicate it.
>
> People write bad exception code - people write bad error return code. It’s
> easier to write and maintain good exception code. To this day, very few major
> systems are written in Go - at some point we have to ask honestly why - I
> think Go’s error handling is an important factor here.
>
> Go can probably get there without exceptions, but it entails standardized
> error declarations, wrapping, inspection, logging, etc. I think the Go2 error
> handling proposals attempt this.
>
>
>> On Feb 15, 2021, at 11:25 AM, Volker Dobler <dr.volke...@ <>gmail.com
>> <http://gmail.com/>> wrote:
>>
>
>> I think there is strong consensus, that the current style of error handling
>> is currently the best option. Nobody has been able to come up with something
>> better (really better, not just more comfortable while ignoring hefty
>> drawbacks).
>>
>> It is true that a loud minority seems to miss exceptions to a point where
>> they are unwilling to even try the language. How much their expertise counts
>> if they never really worked with proper error handling in Go is debatable.
>> Having worked with error returns and exceptions I can tell you that proper
>> error handling with exceptions is much more painful than with errors. But of
>> course: If your infrastructure, your business requirements and your
>> acceptance criteria allow for making any problem a problem of someone else
>> than exceptions are godsend.
>>
>> V.
>>
>> On Sunday, 14 February 2021 at 17:41:18 UTC+1 ren...@ix.netcom.com
>> <http://ix.netcom.com/> wrote:
>> I think ’strong census’ is not accurate - thus the discussions around
>> improving error handling in Go2.
>>
>> Many have commented here and elsewhere that the number one reason they don’t
>> use Go is due to lack of exception handling.
>>
>> > On Feb 14, 2021, at 10:12 AM, Wojciech S. Czarnecki <oh...@ <>fairbe.org
>> > <http://fairbe.org/>> wrote:
>> >
>> > Dnia 2021-02-13, o godz. 17:44:47
>> > Michael MacInnis <michael.p...@ <>gmail.com <http://gmail.com/>>
>> > napisał(a):
>> >
>> >> I've been playing around with reducing error handling boilerplate
>> >
>> > You're not alone. Hundreds of us went into such thinking in the first
>> > weeks
>> > of reading/using Go - yet before we noticed how much more productive we
>> > are with Go's "boilerplate" than we were in languages where handling
>> > errors
>> > (failures) was "a problem of others", including future-us as "others".
>> >
>> > Perceived consensus of the Go community is that "error handling
>> > boilerplate"
>> > is a strong feature. I.e. in normal production software you MUST handle
>> > failures
>> > and you should do it as close as possible to the source of said failure.
>> >
>> > Go helps with that. Even team's proposal was finally retracted:
>> > https://github.com/golang/go/issues/32437
>> > <https://github.com/golang/go/issues/32437> Discussion there is lengthy,
>> > but worth
>> > reading to sense why wider community considers "boilerplate" as asset.
>> >
>> > Error handling proposals umbrella:
>> > https://github.com/golang/go/issues/40432
>> > <https://github.com/golang/go/issues/40432>
>> >
>> >> Michael.
>> >
>> > Hope this helps,
>> >
>> > --
>> > Wojciech S. Czarnecki
>> > << ^oo^ >> OHIR-RIPE
>> >
>> > --
>> > 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...@ <>googlegroups.com <http://googlegroups.com/>.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/golang-nuts/20210214171250.4377c454%40xmint
>> >
>> > <https://groups.google.com/d/msgid/golang-nuts/20210214171250.4377c454%40xmint>.
>> >
>>
>>
>> --
>> 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...@ <>googlegroups.com <http://googlegroups.com/>.
>
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/d9cdb32d-2609-4ae9-a9ff-36830c877245n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/d9cdb32d-2609-4ae9-a9ff-36830c877245n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
>
> --
> 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/32657f71-d9c1-4a79-9528-ad6a73af954cn%40googlegroups.com
>
> <https://groups.google.com/d/msgid/golang-nuts/32657f71-d9c1-4a79-9528-ad6a73af954cn%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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/0A331454-D449-4049-B329-699A07D3EE10%40ix.netcom.com.
