Re: [go-nuts] Error Handling Best Practice (error wrapping)
Let's please all drop this thread. Thanks. Chris, sorry this got derailed. If you want to follow up on something please start a new thread. Thanks. 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Error Handling Best Practice (error wrapping)
One other thing. I’ll say it again. Go is an amazing piece of technology and it is awesome for many type of applications. I think the “fracturing” that may be occurring is because people are using it in cases it is not well suited and they are running into walls, thus the need to add in features the original designers left out intentionally, rather than deciding that Go is not suitable for this application and use something else. People get overly invested in tools. Yes, your learning time and job prospects make this investment bilateral. Still, if you stop doing engineering and instead just use the tool you’ve backed you’re bound to fail. Sent from my iPhone > On Oct 8, 2018, at 11:10 PM, Robert Engels wrote: > > I’m sorry you feel that way. None of my comments on Go were intended to be > abrasive, they were intended to be matter of fact. > > You are mistaken as well if you think I was proposing exceptions as any sort > of silver bullet. They address the exact concerns the OP had. Exceptions also > come with more structure and “process” which can be a negative in some > environments. Thus the trade offs I referenced. > > You can have simple or you can have robust. You can’t have both, but which is > needed is determined by the problem at hand. > > Sent from my iPhone > >> On Oct 8, 2018, at 10:46 PM, Dan Kortschak >> wrote: >> >> OK, I'll have to accept that. >> >> However, in your reply that I responded to you wrote: >> >>> But to each his own, just please don’t work on anything with critical >>> safety issues please. Thanks for your understanding. >> >> This was rude. >> >> Further, to explain my original post. It is a joke talking about >> people, by stealth changing one language to another because the >> destination is the Obviously Correct™ language to use. This struck a >> chord with my with your claims about things that are obviously missing >> from Go that are present in Java and how we as a community in Go should >> just stop fooling around and start doing it the Right Way™. >> >> ISTM that in your comment "Yes, lobby to have Go2 include exceptions >> and then you don’t need to worry about any of this... :)" you are >> indeed suggesting that the actually is a silver bullet, and that Java >> has it and that Go doesn't. It may be the case that I have >> misinterpreted what you wrote (the smiley supports this), but the >> fairly consistent abrasiveness of you posts regarding deficits in Go >> that Java has already solved suggests to me on balance that I haven't. >> If I have, I apologise. >> >> I have nothing further to add to this thread. >> >> Dan >> >>> On Mon, 2018-10-08 at 21:12 -0500, Robert Engels wrote: >>> I was only speaking for James Gosling. Engineering is balancing trade >>> offs, which usually entails choosing the proper tools and processes >>> for the task at hand. >>> >>> There are no silver bullets and taking positions that hinge on them >>> is a fools errand. >>> >>> Sent from my iPhone >>> On Oct 8, 2018, at 8:23 PM, Dan Kortschak >>> du.au> wrote: That is uncalled for. Dan > > On Mon, 2018-10-08 at 20:20 -0500, robert engels wrote: > I don’t think denigrating the most obvious advancement in > computer > software in the last 20 years helps move things forward. > > But to each his own, just please don’t work on anything with > critical > safety issues please. Thanks for your understanding. > > -- > 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. > 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Error Handling Best Practice (error wrapping)
I’m sorry you feel that way. None of my comments on Go were intended to be abrasive, they were intended to be matter of fact. You are mistaken as well if you think I was proposing exceptions as any sort of silver bullet. They address the exact concerns the OP had. Exceptions also come with more structure and “process” which can be a negative in some environments. Thus the trade offs I referenced. You can have simple or you can have robust. You can’t have both, but which is needed is determined by the problem at hand. Sent from my iPhone > On Oct 8, 2018, at 10:46 PM, Dan Kortschak > wrote: > > OK, I'll have to accept that. > > However, in your reply that I responded to you wrote: > >> But to each his own, just please don’t work on anything with critical >> safety issues please. Thanks for your understanding. > > This was rude. > > Further, to explain my original post. It is a joke talking about > people, by stealth changing one language to another because the > destination is the Obviously Correct™ language to use. This struck a > chord with my with your claims about things that are obviously missing > from Go that are present in Java and how we as a community in Go should > just stop fooling around and start doing it the Right Way™. > > ISTM that in your comment "Yes, lobby to have Go2 include exceptions > and then you don’t need to worry about any of this... :)" you are > indeed suggesting that the actually is a silver bullet, and that Java > has it and that Go doesn't. It may be the case that I have > misinterpreted what you wrote (the smiley supports this), but the > fairly consistent abrasiveness of you posts regarding deficits in Go > that Java has already solved suggests to me on balance that I haven't. > If I have, I apologise. > > I have nothing further to add to this thread. > > Dan > >> On Mon, 2018-10-08 at 21:12 -0500, Robert Engels wrote: >> I was only speaking for James Gosling. Engineering is balancing trade >> offs, which usually entails choosing the proper tools and processes >> for the task at hand. >> >> There are no silver bullets and taking positions that hinge on them >> is a fools errand. >> >> Sent from my iPhone >> >>> >>> On Oct 8, 2018, at 8:23 PM, Dan Kortschak >> du.au> wrote: >>> >>> That is uncalled for. >>> >>> Dan >>> On Mon, 2018-10-08 at 20:20 -0500, robert engels wrote: I don’t think denigrating the most obvious advancement in computer software in the last 20 years helps move things forward. But to each his own, just please don’t work on anything with critical safety issues please. Thanks for your understanding. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Error Handling Best Practice (error wrapping)
OK, I'll have to accept that. However, in your reply that I responded to you wrote: > But to each his own, just please don’t work on anything with critical > safety issues please. Thanks for your understanding. This was rude. Further, to explain my original post. It is a joke talking about people, by stealth changing one language to another because the destination is the Obviously Correct™ language to use. This struck a chord with my with your claims about things that are obviously missing from Go that are present in Java and how we as a community in Go should just stop fooling around and start doing it the Right Way™. ISTM that in your comment "Yes, lobby to have Go2 include exceptions and then you don’t need to worry about any of this... :)" you are indeed suggesting that the actually is a silver bullet, and that Java has it and that Go doesn't. It may be the case that I have misinterpreted what you wrote (the smiley supports this), but the fairly consistent abrasiveness of you posts regarding deficits in Go that Java has already solved suggests to me on balance that I haven't. If I have, I apologise. I have nothing further to add to this thread. Dan On Mon, 2018-10-08 at 21:12 -0500, Robert Engels wrote: > I was only speaking for James Gosling. Engineering is balancing trade > offs, which usually entails choosing the proper tools and processes > for the task at hand. > > There are no silver bullets and taking positions that hinge on them > is a fools errand. > > Sent from my iPhone > > > > > On Oct 8, 2018, at 8:23 PM, Dan Kortschak > du.au> wrote: > > > > That is uncalled for. > > > > Dan > > > > > > > > On Mon, 2018-10-08 at 20:20 -0500, robert engels wrote: > > > I don’t think denigrating the most obvious advancement in > > > computer > > > software in the last 20 years helps move things forward. > > > > > > But to each his own, just please don’t work on anything with > > > critical > > > safety issues please. Thanks for your understanding. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Error Handling Best Practice (error wrapping)
I was only speaking for James Gosling. Engineering is balancing trade offs, which usually entails choosing the proper tools and processes for the task at hand. There are no silver bullets and taking positions that hinge on them is a fools errand. Sent from my iPhone > On Oct 8, 2018, at 8:23 PM, Dan Kortschak > wrote: > > That is uncalled for. > > Dan > >> On Mon, 2018-10-08 at 20:20 -0500, robert engels wrote: >> I don’t think denigrating the most obvious advancement in computer >> software in the last 20 years helps move things forward. >> >> But to each his own, just please don’t work on anything with critical >> safety issues please. Thanks for your understanding. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Error Handling Best Practice (error wrapping)
That is uncalled for. Dan On Mon, 2018-10-08 at 20:20 -0500, robert engels wrote: > I don’t think denigrating the most obvious advancement in computer > software in the last 20 years helps move things forward. > > But to each his own, just please don’t work on anything with critical > safety issues please. Thanks for your understanding. -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Error Handling Best Practice (error wrapping)
I don’t think denigrating the most obvious advancement in computer software in the last 20 years helps move things forward. But to each his own, just please don’t work on anything with critical safety issues please. Thanks for your understanding. > On Oct 8, 2018, at 4:03 PM, Dan Kortschak > wrote: > > This is relevant here again. > >> The European Commission has just announced an agreement whereby >> English will be the official language of the European Union rather >> than German, which was the other possibility. >> >> As part of the negotiations, the British Government conceded that >> English spelling had some room for improvement and has accepted a 5- >> year phase-in plan that would become known as "Euro-English". >> >> In the first year, "s" will replace the soft "c". Sertainly, this >> will make the sivil servants jump with joy. The hard "c" will be >> dropped in favour of "k". This should klear up konfusion, and >> keyboards kan have one less letter. >> >> There will be growing publik enthusiasm in the sekond year when the >> troublesome "ph" will be replaced with "f". This will make words like >> fotograf 20% shorter. >> >> In the 3rd year, publik akseptanse of the new spelling kan be >> expekted to reach the stage where more komplikated changes are >> possible. >> >> Governments will enkourage the removal of double letters which have >> always ben a deterent to akurate speling. >> >> Also, al wil agre that the horibl mes of the silent "e" in the >> languag is disgrasful and it should go away. >> >> By the 4th yer peopl wil be reseptiv to steps such as replasing "th" >> with "z" and "w" with "v". >> >> During ze fifz yer, ze unesesary "o" kan be dropd from vords >> kontaining "ou" and after ziz fifz yer, ve vil hav a reil sensi bl >> riten styl. >> >> Zer vil be no mor trubl or difikultis and evrivun vil find it ezi TU >> understand ech oza. Ze drem of a united urop vil finali kum tru. >> >> Und efter ze fifz yer, ve vil al be speking German like zey vunted in >> ze forst plas. > > Replace "German" with "Java". > > On Mon, 2018-10-08 at 08:04 -0500, Robert Engels wrote: >> Yes, lobby to have Go2 include exceptions and then you don’t need to >> worry about any of this... :) > > -- > 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. > 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Error Handling Best Practice (error wrapping)
On Mon, 8 Oct 2018 08:04:46 -0500 Robert Engels wrote: > Yes, lobby to have Go2 include exceptions and then you don’t need to worry > about any of this... :) You only will worry about thousands of things that your predecessors thrown at you just because "the schedule was tight". Is it right time to lobby java ppl about removing 'do' and 'while' and some other twenty three keywords to let Gophers feel better at java? I solemnly promise a post advocating for try/catch construct in Go the day after you will succeed with convincing java's population to a vocabulary size of Go's. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Error Handling Best Practice (error wrapping)
This is relevant here again. > The European Commission has just announced an agreement whereby > English will be the official language of the European Union rather > than German, which was the other possibility. > > As part of the negotiations, the British Government conceded that > English spelling had some room for improvement and has accepted a 5- > year phase-in plan that would become known as "Euro-English". > > In the first year, "s" will replace the soft "c". Sertainly, this > will make the sivil servants jump with joy. The hard "c" will be > dropped in favour of "k". This should klear up konfusion, and > keyboards kan have one less letter. > > There will be growing publik enthusiasm in the sekond year when the > troublesome "ph" will be replaced with "f". This will make words like > fotograf 20% shorter. > > In the 3rd year, publik akseptanse of the new spelling kan be > expekted to reach the stage where more komplikated changes are > possible. > > Governments will enkourage the removal of double letters which have > always ben a deterent to akurate speling. > > Also, al wil agre that the horibl mes of the silent "e" in the > languag is disgrasful and it should go away. > > By the 4th yer peopl wil be reseptiv to steps such as replasing "th" > with "z" and "w" with "v". > > During ze fifz yer, ze unesesary "o" kan be dropd from vords > kontaining "ou" and after ziz fifz yer, ve vil hav a reil sensi bl > riten styl. > > Zer vil be no mor trubl or difikultis and evrivun vil find it ezi TU > understand ech oza. Ze drem of a united urop vil finali kum tru. > > Und efter ze fifz yer, ve vil al be speking German like zey vunted in > ze forst plas. Replace "German" with "Java". On Mon, 2018-10-08 at 08:04 -0500, Robert Engels wrote: > Yes, lobby to have Go2 include exceptions and then you don’t need to > worry about any of this... :) -- 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Error Handling Best Practice (error wrapping)
The Go designers considered and discarded exceptions for common errors,
then added panic/recover for truly exceptional circumstance. There are
known problems with try/catch:
https://en.wikipedia.org/wiki/Exception_handling#Criticism
I've posted a comprehensive list of "possible requirements" for Go2 error
handling. If it's missing any concepts that try/catch provides, could you
raise them?
https://gist.github.com/networkimprov/961c9caa2631ad3b95413f7d44a2c98a
That page is linked from the feedback wiki I posted previously.
On Monday, October 8, 2018 at 10:37:43 AM UTC-7, Robert Engels wrote:
>
> I don’t think any of hat is true. Java has exceptions, it is highly
> concurrent and it is very efficient.
>
> I just think that by the time yo get all of the “features” into Go error
> handling that it needs for both reliability, debugging, etc., you are going
> to end up with “exceptions” just with a different name and syntax - so I
> say - why not just implement them to begin with. Passing errors up stream
> (which is often the only reasonable thing to do in a complex system) is
> error prone without stack traces (for logging), and types (for handling).
>
> The only difference between Go and Java here would be that Go’s are
> interface based, where as in Java it uses a type hierarchy based off
> Throwable.
>
> You can write poor Go error code now, there would be nothing stopping
> someone from writing poor error code using exceptions, except at least with
> exceptions it is obvious (by the catch and throw clauses) which errors the
> code is handling and how… (if at all in bad code). With the current Go
> error handling and the ability to use ‘_’ coupled with no API that controls
> what errors can be seen/emitted (other than reading the specific API method
> documentation, and even here you have to get lucky, including with the
> stdlib methods) - complex error situations in Go are much harder to handle.
>
> Simple situations are easy in Go right now, but the ‘error mechanism’ is
> more flow control than error handling in many cases.
>
>
> On Oct 8, 2018, at 12:07 PM, Chris Hopkins > wrote:
>
> {initial long rabley post deleted}
>
> If I understand the exception proposals, they are quite un-go-like. That
> is go as a strongly typed, "no undeclared variables", etc language sits on
> the side of more effort upfront to produce fewer bugs later trade-off. Try
> ... catch however is more of the rough and ready "don't worry about the
> details until I absolutely have to" philosophy.
> That's not to say they would be wrong for go, I just got the impression
> exceptions - like interrupts - did not play well with concurrency and large
> projects in general (Except in a "stop the world, I've subbed my toe" kind
> of way).
>
> I can see for many classes of problems they could work very well and
> certainly be convenient, but are they not kind of a "Forget about any
> issues I might have, someone else will fix it" philosophy?
>
> {Hardware Engineer hat on}
> I can't help but think that Exceptions in the hardware sense are a costly
> thing, in terms of latency, context switch and the higher level handler
> trying to clean up the state afterwards. In a multi-processor system this
> gets MUCH worse. They are errors in the strictest sense that should be rare.
> Perhaps this viewpoint is shading my outlook, of the different concept of
> exceptions here.
> {Hat off}
>
> But I think that's what this is, not a question of utility, but of
> philosophy, what type of language do people want go to be? Which scales to
> large systems better? What is easier to understand when someone else has
> written it?
> I guess my fear of a catch type mechanism is coming along to find an
> exception firing in someone else's code and all I see is "Out of Cheese
> error", where that's an error that's used at every place in the code
> anything goes wrong (I joke, but how many times have I seen code that just
> goes log.Fatal("Error")). I could then come along and re-write every one of
> those places to use different errors, but I would hope most people would
> say that that behaviour was bad practice, to be fixed. I believe exceptions
> would encourage, not discourage that behaviour.
>
> Sorry, my short post ended up quite long too!
>
> Regards
>
> Chris
> On Monday, 8 October 2018 16:46:28 UTC+1, Robert Engels wrote:
>>
>> I read the proposal and the only knock against including a stack trace by
>> default is one google problem cited that was clearly bad error handling to
>> begin with.
>>
>> Why is there always some need to reinvent the wheel. Leave Go error
>> handling as in and add a throws and catch that new code can use, with the
>> current const based error instances - just add an interface Exception that
>> all throw X need to implement in order to use, and catch on interfaces, not
>> structs.
>>
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nu
Re: [go-nuts] Error Handling Best Practice (error wrapping)
Note that the check/handle proposal has largely prompted counter-proposals and critique... https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback So I'd guess that the final product will look rather different :-) On Monday, October 8, 2018 at 7:54:54 AM UTC-7, Chris Hopkins wrote: > > Thanks. Yes, that's exactly what I want, could I have Go2 now please? ;-) > > Okay I'll keep doing it the way I'm doing it with a mind to swapping to > that when available. > > I had avoided reading the Go2 proposal stuff simply because I regard > language design as a question for people with Marvin-like intellects. > That's way less scary than the generics proposals that worry me so much. > > Thanks again > > On Monday, 8 October 2018 15:33:07 UTC+1, Ian Lance Taylor wrote: >> >> On Mon, Oct 8, 2018 at 3:38 AM, Chris Hopkins >> wrote: >> > Hi, >> > Could I please check what current error handling best practice is? >> ... >> > Any suggestions gratefully received. >> >> Have you seen the error handling thoughts at >> https://go.googlesource.com/proposal/+/master/design/go2draft.md ? >> The thoughts about "errors as values" seems relevant here. >> >> 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. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Error Handling Best Practice (error wrapping)
I don’t think any of hat is true. Java has exceptions, it is highly concurrent
and it is very efficient.
I just think that by the time yo get all of the “features” into Go error
handling that it needs for both reliability, debugging, etc., you are going to
end up with “exceptions” just with a different name and syntax - so I say - why
not just implement them to begin with. Passing errors up stream (which is often
the only reasonable thing to do in a complex system) is error prone without
stack traces (for logging), and types (for handling).
The only difference between Go and Java here would be that Go’s are interface
based, where as in Java it uses a type hierarchy based off Throwable.
You can write poor Go error code now, there would be nothing stopping someone
from writing poor error code using exceptions, except at least with exceptions
it is obvious (by the catch and throw clauses) which errors the code is
handling and how… (if at all in bad code). With the current Go error handling
and the ability to use ‘_’ coupled with no API that controls what errors can be
seen/emitted (other than reading the specific API method documentation, and
even here you have to get lucky, including with the stdlib methods) - complex
error situations in Go are much harder to handle.
Simple situations are easy in Go right now, but the ‘error mechanism’ is more
flow control than error handling in many cases.
> On Oct 8, 2018, at 12:07 PM, Chris Hopkins wrote:
>
> {initial long rabley post deleted}
>
> If I understand the exception proposals, they are quite un-go-like. That is
> go as a strongly typed, "no undeclared variables", etc language sits on the
> side of more effort upfront to produce fewer bugs later trade-off. Try ...
> catch however is more of the rough and ready "don't worry about the details
> until I absolutely have to" philosophy.
> That's not to say they would be wrong for go, I just got the impression
> exceptions - like interrupts - did not play well with concurrency and large
> projects in general (Except in a "stop the world, I've subbed my toe" kind of
> way).
>
> I can see for many classes of problems they could work very well and
> certainly be convenient, but are they not kind of a "Forget about any issues
> I might have, someone else will fix it" philosophy?
>
> {Hardware Engineer hat on}
> I can't help but think that Exceptions in the hardware sense are a costly
> thing, in terms of latency, context switch and the higher level handler
> trying to clean up the state afterwards. In a multi-processor system this
> gets MUCH worse. They are errors in the strictest sense that should be rare.
> Perhaps this viewpoint is shading my outlook, of the different concept of
> exceptions here.
> {Hat off}
>
> But I think that's what this is, not a question of utility, but of
> philosophy, what type of language do people want go to be? Which scales to
> large systems better? What is easier to understand when someone else has
> written it?
> I guess my fear of a catch type mechanism is coming along to find an
> exception firing in someone else's code and all I see is "Out of Cheese
> error", where that's an error that's used at every place in the code anything
> goes wrong (I joke, but how many times have I seen code that just goes
> log.Fatal("Error")). I could then come along and re-write every one of those
> places to use different errors, but I would hope most people would say that
> that behaviour was bad practice, to be fixed. I believe exceptions would
> encourage, not discourage that behaviour.
>
> Sorry, my short post ended up quite long too!
>
> Regards
>
> Chris
> On Monday, 8 October 2018 16:46:28 UTC+1, Robert Engels wrote:
> I read the proposal and the only knock against including a stack trace by
> default is one google problem cited that was clearly bad error handling to
> begin with.
>
> Why is there always some need to reinvent the wheel. Leave Go error handling
> as in and add a throws and catch that new code can use, with the current
> const based error instances - just add an interface Exception that all throw
> X need to implement in order to use, and catch on interfaces, not structs.
>
> On Oct 8, 2018, at 9:54 AM, Chris Hopkins > wrote:
>
>> Thanks. Yes, that's exactly what I want, could I have Go2 now please? ;-)
>>
>> Okay I'll keep doing it the way I'm doing it with a mind to swapping to that
>> when available.
>>
>> I had avoided reading the Go2 proposal stuff simply because I regard
>> language design as a question for people with Marvin-like intellects. That's
>> way less scary than the generics proposals that worry me so much.
>>
>> Thanks again
>>
>> On Monday, 8 October 2018 15:33:07 UTC+1, Ian Lance Taylor wrote:
>> On Mon, Oct 8, 2018 at 3:38 AM, Chris Hopkins > wrote:
>> > Hi,
>> > Could I please check what current error handling best practice is?
>> > I've gotten quite smitten with github.com/pkg/errors
>
Re: [go-nuts] Error Handling Best Practice (error wrapping)
{initial long rabley post deleted}
If I understand the exception proposals, they are quite un-go-like. That is
go as a strongly typed, "no undeclared variables", etc language sits on the
side of more effort upfront to produce fewer bugs later trade-off. Try ...
catch however is more of the rough and ready "don't worry about the details
until I absolutely have to" philosophy.
That's not to say they would be wrong for go, I just got the impression
exceptions - like interrupts - did not play well with concurrency and large
projects in general (Except in a "stop the world, I've subbed my toe" kind
of way).
I can see for many classes of problems they could work very well and
certainly be convenient, but are they not kind of a "Forget about any
issues I might have, someone else will fix it" philosophy?
{Hardware Engineer hat on}
I can't help but think that Exceptions in the hardware sense are a costly
thing, in terms of latency, context switch and the higher level handler
trying to clean up the state afterwards. In a multi-processor system this
gets MUCH worse. They are errors in the strictest sense that should be rare.
Perhaps this viewpoint is shading my outlook, of the different concept of
exceptions here.
{Hat off}
But I think that's what this is, not a question of utility, but of
philosophy, what type of language do people want go to be? Which scales to
large systems better? What is easier to understand when someone else has
written it?
I guess my fear of a catch type mechanism is coming along to find an
exception firing in someone else's code and all I see is "Out of Cheese
error", where that's an error that's used at every place in the code
anything goes wrong (I joke, but how many times have I seen code that just
goes log.Fatal("Error")). I could then come along and re-write every one of
those places to use different errors, but I would hope most people would
say that that behaviour was bad practice, to be fixed. I believe exceptions
would encourage, not discourage that behaviour.
Sorry, my short post ended up quite long too!
Regards
Chris
On Monday, 8 October 2018 16:46:28 UTC+1, Robert Engels wrote:
>
> I read the proposal and the only knock against including a stack trace by
> default is one google problem cited that was clearly bad error handling to
> begin with.
>
> Why is there always some need to reinvent the wheel. Leave Go error
> handling as in and add a throws and catch that new code can use, with the
> current const based error instances - just add an interface Exception that
> all throw X need to implement in order to use, and catch on interfaces, not
> structs.
>
> On Oct 8, 2018, at 9:54 AM, Chris Hopkins > wrote:
>
> Thanks. Yes, that's exactly what I want, could I have Go2 now please? ;-)
>
> Okay I'll keep doing it the way I'm doing it with a mind to swapping to
> that when available.
>
> I had avoided reading the Go2 proposal stuff simply because I regard
> language design as a question for people with Marvin-like intellects.
> That's way less scary than the generics proposals that worry me so much.
>
> Thanks again
>
> On Monday, 8 October 2018 15:33:07 UTC+1, Ian Lance Taylor wrote:
>>
>> On Mon, Oct 8, 2018 at 3:38 AM, Chris Hopkins
>> wrote:
>> > Hi,
>> > Could I please check what current error handling best practice is?
>> > I've gotten quite smitten with github.com/pkg/errors. I really like
>> the
>> > ability to create a stack of errors that trace to what is going on.
>> However
>> > it seems this is not an often used package - it's not available in
>> > playground for example. It's really useful for diagnostics to see a
>> stack of
>> > what is causing an error, however in my latest application where I'm
>> trying
>> > to be really rigorous with my error handling I've hit - for want of a
>> better
>> > word - an imperfection. Could I check if there's a better way to do
>> these
>> > things:
>> > So here's what I'm doing:
>> > When I have an error I need to report I create it like this:
>> > var ErrInvalidVariable = errors.New("Invalid Variable")
>> > Which means that you can have code that nicely reads:
>> > if err == ErrInvalidVariable { /* handle this error */}
>> > It's how the os package reports errors (along with helper functions),
>> so I
>> > assume this is the correct way.
>> >
>> >
>> > For better debug I can use errors.Wrap to annotate this error through
>> the
>> > error stack and get useful diagnostic printouts such as
>> > Line Processing passed "if $BOB==3": Token Passed $BOB : Invalid
>> Variable.
>> >
>> > So far so good. This starts to fail though if I'm trying to determine
>> lets
>> > say a fileio error that came from the config file reader, vs the script
>> file
>> > reader. At the moment I can say
>> > _, err := os.Open(...)
>> > if err != nil {
>> > return errors.Wrap(err, "Config File read error")
>> > }
>> > But without searching through the error text I can't tell w
Re: [go-nuts] Error Handling Best Practice (error wrapping)
I read the proposal and the only knock against including a stack trace by
default is one google problem cited that was clearly bad error handling to
begin with.
Why is there always some need to reinvent the wheel. Leave Go error handling as
in and add a throws and catch that new code can use, with the current const
based error instances - just add an interface Exception that all throw X need
to implement in order to use, and catch on interfaces, not structs.
> On Oct 8, 2018, at 9:54 AM, Chris Hopkins wrote:
>
> Thanks. Yes, that's exactly what I want, could I have Go2 now please? ;-)
>
> Okay I'll keep doing it the way I'm doing it with a mind to swapping to that
> when available.
>
> I had avoided reading the Go2 proposal stuff simply because I regard language
> design as a question for people with Marvin-like intellects. That's way less
> scary than the generics proposals that worry me so much.
>
> Thanks again
>
>> On Monday, 8 October 2018 15:33:07 UTC+1, Ian Lance Taylor wrote:
>> On Mon, Oct 8, 2018 at 3:38 AM, Chris Hopkins wrote:
>> > Hi,
>> > Could I please check what current error handling best practice is?
>> > I've gotten quite smitten with github.com/pkg/errors. I really like the
>> > ability to create a stack of errors that trace to what is going on.
>> > However
>> > it seems this is not an often used package - it's not available in
>> > playground for example. It's really useful for diagnostics to see a stack
>> > of
>> > what is causing an error, however in my latest application where I'm
>> > trying
>> > to be really rigorous with my error handling I've hit - for want of a
>> > better
>> > word - an imperfection. Could I check if there's a better way to do these
>> > things:
>> > So here's what I'm doing:
>> > When I have an error I need to report I create it like this:
>> > var ErrInvalidVariable = errors.New("Invalid Variable")
>> > Which means that you can have code that nicely reads:
>> > if err == ErrInvalidVariable { /* handle this error */}
>> > It's how the os package reports errors (along with helper functions), so I
>> > assume this is the correct way.
>> >
>> >
>> > For better debug I can use errors.Wrap to annotate this error through the
>> > error stack and get useful diagnostic printouts such as
>> > Line Processing passed "if $BOB==3": Token Passed $BOB : Invalid Variable.
>> >
>> > So far so good. This starts to fail though if I'm trying to determine lets
>> > say a fileio error that came from the config file reader, vs the script
>> > file
>> > reader. At the moment I can say
>> > _, err := os.Open(...)
>> > if err != nil {
>> > return errors.Wrap(err, "Config File read error")
>> > }
>> > But without searching through the error text I can't tell who caused that.
>> > Now I could declare a specific type for this, add a Cause handler onto
>> > that,
>> > but it starts to get clunky to do that for every error condition. Also it
>> > doesn't scale to more than 2 levels because it stops at the first cause
>> > found. I can obviously work around this, but I'm thinking I'm doing this
>> > wrong, a defining feature of go is the error handling - surely there's a
>> > better way to do it than this!.
>> >
>> > Am I doing something unusual here and wanting to determine where in the
>> > hierarchy of the stack a problem might have come from? How else do people
>> > handle errors in situations like this, where you can't fully handle them
>> > locally, so you want to return the error, but then when you get to the
>> > higher levels you can handle them, as long as you have information about
>> > the
>> > error. The annoying thing is, everything is there in the string of the
>> > error
>> > message and I could strings.Contains my way through the error string to
>> > work
>> > this out, but that feels a really stupid way to do this.
>> > I also come across this in my test cases, I want to inject error to make
>> > sure I am spotting errors correctly and checking that I am getting the
>> > correct error from the correct place is really quite clunky at the moment,
>> > if I could test that an error checker in location X was triggered by it
>> > being passed an error that would save me a lot of code.
>> >
>> > Any suggestions gratefully received.
>>
>> Have you seen the error handling thoughts at
>> https://go.googlesource.com/proposal/+/master/design/go2draft.md ?
>> The thoughts about "errors as values" seems relevant here.
>>
>> 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.
> 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
Re: [go-nuts] Error Handling Best Practice (error wrapping)
Thanks. Yes, that's exactly what I want, could I have Go2 now please? ;-)
Okay I'll keep doing it the way I'm doing it with a mind to swapping to
that when available.
I had avoided reading the Go2 proposal stuff simply because I regard
language design as a question for people with Marvin-like intellects.
That's way less scary than the generics proposals that worry me so much.
Thanks again
On Monday, 8 October 2018 15:33:07 UTC+1, Ian Lance Taylor wrote:
>
> On Mon, Oct 8, 2018 at 3:38 AM, Chris Hopkins > wrote:
> > Hi,
> > Could I please check what current error handling best practice is?
> > I've gotten quite smitten with github.com/pkg/errors. I really like the
> > ability to create a stack of errors that trace to what is going on.
> However
> > it seems this is not an often used package - it's not available in
> > playground for example. It's really useful for diagnostics to see a
> stack of
> > what is causing an error, however in my latest application where I'm
> trying
> > to be really rigorous with my error handling I've hit - for want of a
> better
> > word - an imperfection. Could I check if there's a better way to do
> these
> > things:
> > So here's what I'm doing:
> > When I have an error I need to report I create it like this:
> > var ErrInvalidVariable = errors.New("Invalid Variable")
> > Which means that you can have code that nicely reads:
> > if err == ErrInvalidVariable { /* handle this error */}
> > It's how the os package reports errors (along with helper functions), so
> I
> > assume this is the correct way.
> >
> >
> > For better debug I can use errors.Wrap to annotate this error through
> the
> > error stack and get useful diagnostic printouts such as
> > Line Processing passed "if $BOB==3": Token Passed $BOB : Invalid
> Variable.
> >
> > So far so good. This starts to fail though if I'm trying to determine
> lets
> > say a fileio error that came from the config file reader, vs the script
> file
> > reader. At the moment I can say
> > _, err := os.Open(...)
> > if err != nil {
> > return errors.Wrap(err, "Config File read error")
> > }
> > But without searching through the error text I can't tell who caused
> that.
> > Now I could declare a specific type for this, add a Cause handler onto
> that,
> > but it starts to get clunky to do that for every error condition. Also
> it
> > doesn't scale to more than 2 levels because it stops at the first cause
> > found. I can obviously work around this, but I'm thinking I'm doing this
> > wrong, a defining feature of go is the error handling - surely there's a
> > better way to do it than this!.
> >
> > Am I doing something unusual here and wanting to determine where in the
> > hierarchy of the stack a problem might have come from? How else do
> people
> > handle errors in situations like this, where you can't fully handle them
> > locally, so you want to return the error, but then when you get to the
> > higher levels you can handle them, as long as you have information about
> the
> > error. The annoying thing is, everything is there in the string of the
> error
> > message and I could strings.Contains my way through the error string to
> work
> > this out, but that feels a really stupid way to do this.
> > I also come across this in my test cases, I want to inject error to make
> > sure I am spotting errors correctly and checking that I am getting the
> > correct error from the correct place is really quite clunky at the
> moment,
> > if I could test that an error checker in location X was triggered by it
> > being passed an error that would save me a lot of code.
> >
> > Any suggestions gratefully received.
>
> Have you seen the error handling thoughts at
> https://go.googlesource.com/proposal/+/master/design/go2draft.md ?
> The thoughts about "errors as values" seems relevant here.
>
> 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.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Error Handling Best Practice (error wrapping)
On Mon, Oct 8, 2018 at 3:38 AM, Chris Hopkins wrote:
> Hi,
> Could I please check what current error handling best practice is?
> I've gotten quite smitten with github.com/pkg/errors. I really like the
> ability to create a stack of errors that trace to what is going on. However
> it seems this is not an often used package - it's not available in
> playground for example. It's really useful for diagnostics to see a stack of
> what is causing an error, however in my latest application where I'm trying
> to be really rigorous with my error handling I've hit - for want of a better
> word - an imperfection. Could I check if there's a better way to do these
> things:
> So here's what I'm doing:
> When I have an error I need to report I create it like this:
> var ErrInvalidVariable = errors.New("Invalid Variable")
> Which means that you can have code that nicely reads:
> if err == ErrInvalidVariable { /* handle this error */}
> It's how the os package reports errors (along with helper functions), so I
> assume this is the correct way.
>
>
> For better debug I can use errors.Wrap to annotate this error through the
> error stack and get useful diagnostic printouts such as
> Line Processing passed "if $BOB==3": Token Passed $BOB : Invalid Variable.
>
> So far so good. This starts to fail though if I'm trying to determine lets
> say a fileio error that came from the config file reader, vs the script file
> reader. At the moment I can say
> _, err := os.Open(...)
> if err != nil {
> return errors.Wrap(err, "Config File read error")
> }
> But without searching through the error text I can't tell who caused that.
> Now I could declare a specific type for this, add a Cause handler onto that,
> but it starts to get clunky to do that for every error condition. Also it
> doesn't scale to more than 2 levels because it stops at the first cause
> found. I can obviously work around this, but I'm thinking I'm doing this
> wrong, a defining feature of go is the error handling - surely there's a
> better way to do it than this!.
>
> Am I doing something unusual here and wanting to determine where in the
> hierarchy of the stack a problem might have come from? How else do people
> handle errors in situations like this, where you can't fully handle them
> locally, so you want to return the error, but then when you get to the
> higher levels you can handle them, as long as you have information about the
> error. The annoying thing is, everything is there in the string of the error
> message and I could strings.Contains my way through the error string to work
> this out, but that feels a really stupid way to do this.
> I also come across this in my test cases, I want to inject error to make
> sure I am spotting errors correctly and checking that I am getting the
> correct error from the correct place is really quite clunky at the moment,
> if I could test that an error checker in location X was triggered by it
> being passed an error that would save me a lot of code.
>
> Any suggestions gratefully received.
Have you seen the error handling thoughts at
https://go.googlesource.com/proposal/+/master/design/go2draft.md ?
The thoughts about "errors as values" seems relevant here.
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.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Error Handling Best Practice (error wrapping)
Yes, lobby to have Go2 include exceptions and then you don’t need to worry
about any of this... :)
> On Oct 8, 2018, at 5:38 AM, Chris Hopkins wrote:
>
> Hi,
> Could I please check what current error handling best practice is?
> I've gotten quite smitten with github.com/pkg/errors. I really like the
> ability to create a stack of errors that trace to what is going on. However
> it seems this is not an often used package - it's not available in playground
> for example. It's really useful for diagnostics to see a stack of what is
> causing an error, however in my latest application where I'm trying to be
> really rigorous with my error handling I've hit - for want of a better word -
> an imperfection. Could I check if there's a better way to do these things:
> So here's what I'm doing:
> When I have an error I need to report I create it like this:
> var ErrInvalidVariable = errors.New("Invalid Variable")
> Which means that you can have code that nicely reads:
> if err == ErrInvalidVariable { /* handle this error */}
> It's how the os package reports errors (along with helper functions), so I
> assume this is the correct way.
>
>
> For better debug I can use errors.Wrap to annotate this error through the
> error stack and get useful diagnostic printouts such as
> Line Processing passed "if $BOB==3": Token Passed $BOB : Invalid Variable.
>
> So far so good. This starts to fail though if I'm trying to determine lets
> say a fileio error that came from the config file reader, vs the script file
> reader. At the moment I can say
> _, err := os.Open(...)
> if err != nil {
> return errors.Wrap(err, "Config File read error")
> }
> But without searching through the error text I can't tell who caused that.
> Now I could declare a specific type for this, add a Cause handler onto that,
> but it starts to get clunky to do that for every error condition. Also it
> doesn't scale to more than 2 levels because it stops at the first cause
> found. I can obviously work around this, but I'm thinking I'm doing this
> wrong, a defining feature of go is the error handling - surely there's a
> better way to do it than this!.
>
> Am I doing something unusual here and wanting to determine where in the
> hierarchy of the stack a problem might have come from? How else do people
> handle errors in situations like this, where you can't fully handle them
> locally, so you want to return the error, but then when you get to the higher
> levels you can handle them, as long as you have information about the error.
> The annoying thing is, everything is there in the string of the error message
> and I could strings.Contains my way through the error string to work this
> out, but that feels a really stupid way to do this.
> I also come across this in my test cases, I want to inject error to make sure
> I am spotting errors correctly and checking that I am getting the correct
> error from the correct place is really quite clunky at the moment, if I could
> test that an error checker in location X was triggered by it being passed an
> error that would save me a lot of code.
>
> Any suggestions gratefully received.
>
> Regards
>
> Chris
> --
> 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.
> 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.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] Error Handling Best Practice (error wrapping)
Hi,
Could I please check what current error handling best practice is?
I've gotten quite smitten with github.com/pkg/errors. I really like the
ability to create a stack of errors that trace to what is going on. However
it seems this is not an often used package - it's not available in
playground for example. It's really useful for diagnostics to see a stack
of what is causing an error, however in my latest application where I'm
trying to be really rigorous with my error handling I've hit - for want of
a better word - an imperfection. Could I check if there's a better way to
do these things:
So here's what I'm doing:
When I have an error I need to report I create it like this:
var ErrInvalidVariable = errors.New("Invalid Variable")
Which means that you can have code that nicely reads:
if err == ErrInvalidVariable { /* handle this error */}
It's how the os package reports errors (along with helper functions), so I
assume this is the correct way.
For better debug I can use errors.Wrap to annotate this error through the
error stack and get useful diagnostic printouts such as
Line Processing passed "if $BOB==3": Token Passed $BOB : Invalid Variable.
So far so good. This starts to fail though if I'm trying to determine lets
say a fileio error that came from the config file reader, vs the script
file reader. At the moment I can say
_, err := os.Open(...)
if err != nil {
return errors.Wrap(err, "Config File read error")
}
But without searching through the error text I can't tell who caused that.
Now I could declare a specific type for this, add a Cause handler onto
that, but it starts to get clunky to do that for every error condition.
Also it doesn't scale to more than 2 levels because it stops at the first
cause found. I can obviously work around this, but I'm thinking I'm doing
this wrong, a defining feature of go is the error handling - surely there's
a better way to do it than this!.
Am I doing something unusual here and wanting to determine where in the
hierarchy of the stack a problem might have come from? How else do people
handle errors in situations like this, where you can't fully handle them
locally, so you want to return the error, but then when you get to the
higher levels you can handle them, as long as you have information about
the error. The annoying thing is, everything is there in the string of the
error message and I could strings.Contains my way through the error string
to work this out, but that feels a really stupid way to do this.
I also come across this in my test cases, I want to inject error to make
sure I am spotting errors correctly and checking that I am getting the
correct error from the correct place is really quite clunky at the moment,
if I could test that an error checker in location X was triggered by it
being passed an error that would save me a lot of code.
Any suggestions gratefully received.
Regards
Chris
--
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.
For more options, visit https://groups.google.com/d/optout.
