On Mon, Sep 11, 2017 at 08:49:30PM +1200, Tim Uckun wrote:
> | However, what's great for avoiding straightforward failures becomes a
> | nightmare when your goal is to guarantee that no undefined behaviour
> | happens
>
> It seems to me that if this is your goal other languages are more suitable.
| However, what's great for avoiding straightforward failures becomes a
| nightmare when your goal is to guarantee that no undefined behaviour
| happens
It seems to me that if this is your goal other languages are more suitable.
Erlang for example is famous for it's error handling capability, elm
On Wed, Sep 06, 2017 at 11:00:08PM -0700, Tim Uckun wrote:
> Totally not a go programmer but here are my worthless two cents.
>
> I don't see anything wrong with the try catch paradigm, you can choose your
> granularity. If you want to check every call then you can, if you want to
> let a few c
The solution to Close returning an error, is to defer Close() and then have
a second Close() with error checking in the happy path.
I just wish the io.Closer contract would require, that this has to be safe
(= not panic). Luckily it is, for the vast majority of Closers at least.
On Fri, Sep 8, 20
>
> P.S. someone else proposed wrapper with error handling in defer.
> IMO it is as bad as watch - spooky, at distance, clunky.
>
That was me. My background is many years of C++ and it feels natural to me
(RAII). I follow the pattern: there must be defer Close immediately after
acquire action
Sure! I'm happy to listen to the experience of you all and to keep working
using the existent approach. Thanks, everyone. Dorival
On Friday, September 8, 2017 at 10:29:02 PM UTC+10, Marvin Renich wrote:
>
> * Dorival Pedroso [170908 02:08]:
> > The "watch" strategy would, of course, allow us to
* Dorival Pedroso [170908 02:08]:
> The "watch" strategy would, of course, allow us to do the important steps
> you've mentioned (e.g. clean up and so on).
>
> For instance:
> watch err != nil {
> // do the important things
> return err
> }
Except that "do the important things" often de
On Thu, 7 Sep 2017 17:03:06 -0700 (PDT)
Dorival Pedroso wrote:
> Wouldn't be great to have a "syntactical sugar" to make things (at least a
> little bit) simpler in our beloved Go language?
No. Proposed (*also by past me*) "watch" construct is bad for anyone
reading code, bad for code consiste
please replace:
"will return immediately to the [...]"
with
"will jump immediately to the [...]"
(sorry)
On Friday, September 8, 2017 at 4:07:35 PM UTC+10, Dorival Pedroso wrote:
>
> Hi Dave,
>
> The "watch" strategy would, of course, allow us to do the important steps
> you've mentioned (e.g. cl
Hi Dave,
The "watch" strategy would, of course, allow us to do the important steps
you've mentioned (e.g. clean up and so on).
For instance:
watch err != nil {
// do the important things
return err
}
The watch basically "groups common tasks".
For example, If we have so many tasks, we c
>
>
> Wouldn't be great to have a "syntactical sugar" to make things (at least a
> little bit) simpler in our beloved Go language?
>
>>
>>
no, I don't think so.
Something that few in in this thread have focused on is the most important
part of the go error handling story happens *before* the `
Yes, Nigel! try/catch in Python may at times looks uglier that err != nil.
I think the reason try/catch didn't bother us in C++ is that we had lots of
macros to simplify the work...
In Go, we don't have macros but we don't need to wrap things with "try" and
just need to "recover" panics, I thin
On Thu, Sep 7, 2017 at 4:00 PM, Tim Uckun wrote:
> I don't see anything wrong with the try catch paradigm,
Try-catch makes for shorter code when you're just passing the buck,
but it can be quite complicated when you actually need to handle the
buck.
My showcase example for this is the exception-
On Thu, 7 Sep 2017 05:00:18 -0700 (PDT)
martin.r...@programmfabrik.de wrote:
> lhow about this, and it is a construct which can be used not only for
> errors:
> watch err != nil {
> yo1, err = do_stuff1()
> yo2, err = do_stuff2()
> yo3, err = do_stuff3()
> } then {
> // handle your error
> }
W
On Thu, Sep 7, 2017 at 2:41 PM, Tim Uckun wrote:
> >I *like* the way go does error passing, *because* it's constrained to
> handle errors explicitly.
>
> But it doesn't though. You can completely ignore the errors if you want. >
>
This seems to be, at best, a nit-picky uncharitable reading of wh
Hi Tim
If you want halt the app, you should call panic, that's already a go
built-in. Think it would apply to your proposal as well, despite i do not
agree with it.
Cheers snmed
Am Donnerstag, 7. September 2017 14:42:12 UTC+2 schrieb Tim Uckun:
>
> >I *like* the way go does error passing, *bec
>I *like* the way go does error passing, *because* it's constrained to
handle errors explicitly.
But it doesn't though. You can completely ignore the errors if you want. >
>TBH, no. Not only do I not know what this is supposed to be doing
(err.pop? of what? Why are we assigning to error? What is
I'd hate to debug this: which function has returned the error? What failed,
what succeeded?
--
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.
On Tuesday, September 5, 2017 at 10:39:05 AM UTC+2, Rob 'Commander' Pike
wrote:
>
> If you find that lines like if err != nil are a significant fraction
> of non-test code, your code probably needs a better error handling
> strategy, not a language change. I have done measurements in the past
>
On Thu, Sep 7, 2017 at 8:00 AM, Tim Uckun wrote:
> I don't see anything wrong with the try catch paradigm, you can choose
> your granularity. If you want to check every call then you can, if you want
> to let a few cluster together you can. You guys make is sound like go style
> error handling is
Agreed, Tim.
This discussion helped me to realise that try/catch is pretty good; e.g. we
never even bothered discussing this topic in our C++
code http://mechsys.nongnu.org/ at all...
In the end of the day, we want to treat ALL errors (obviously...).
Go is great that we have two approaches.
R
Totally not a go programmer but here are my worthless two cents.
I don't see anything wrong with the try catch paradigm, you can choose your
granularity. If you want to check every call then you can, if you want to
let a few cluster together you can. You guys make is sound like go style
error
I use what I would call as *error context*.
Here is the simple definition of the *error context*:
type ErrorContext interface {
ContainsError() bool
SetError(err error)
Error() error
}
Here is how you would use it inside the error-prone function:
func FragileFunction(ctx ErrorContex
Hi Michael,
I fully agree with handling each single error ("health issue") as they are
discovered.
The idea of "watch" is NOT to replace this procedure.
It's just a "syntactic sugar" to do what you are doing already.
Cheers.
Dorival
--
You received this message because you are subscribed to
...Go is not perfect. But there is subtle magic in this error business.
Developers should look closely at errors. Imagine handling them as if you
were a doctor and the error was a child's symptom or a test result. Choices:
1. Ask them how they feel, ignore it. Do a test, ignore it. Effectively you
Since *defer* "is the last thing to happen", I think this code is all right:
func something() (x int, err error) {
watch err != nil {
return
}
res, err = acquireResource()
defer func() {
if err == nil {
err = res.Close()
}
}()
err = abc1(
Hi, yes we need the check condition you had before in defer. That seems fine.
But there may be some other problems I haven't thought of. Cheers
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving em
What about?
func something() (x int, err error) {
watch err != nil { // this is only required to watch out in case "err"
ever becomes non-nil
return // the error will propagate outside (same as "return err")
}
res, err = acquireResource() // will return straightway (because we
What about the following?
func something() (x int, err error) {
watch err != nil { // this is only required to watch out in case "err"
ever becomes non-nil
return // the error will propagate outside (same as "return err")
}
res, err = acquireResource() // will return straightw
What about the following?
func something() (x int, err error) {
watch err != nil { // this is only required to watch out in case "err"
ever becomes non-nil
return // the error will propagate outside (same as "return err")
}
res, err = acquireResource() // will return straightw
I've been doing something like this for long chains where "handle error" is
the same:
func something() (x int, err error) {
defer func() {
if err != nil {
// handle error
}
}()
res, err = acquireResource()
if err == nil {
defer func() {
Or you know, just panic ... errors as value are a convention, not a
language construct.
panic/defer ARE a language construct. I personally give the choice in my
API, Must prefixed methods that panic or regular methods that return an
error.
The obvious advantage of panics is that the developer a
Thanks again, Rob.
The blog post (https://blog.golang.org/errors-are-values) does shed some
light.
One of the ideas is to hold the *err* variable in a structure. I will
definitively use this more often (I do have many structures and never
thought of doing this!)---Thanks!
The other idea is to
Exactly: a good amount of "if err != nil" appears in my tests (334 out of
569). I'll try to re-think the other cases...
(e.g. https://github.com/cpmech/gosl/blob/master/la/blas2.go)
No complaints here, by the way! Just enjoying this marvellous language!
I'll read the blog post.
Cheers.
On Tues
If you find that lines like if err != nil are a significant fraction
of non-test code, your code probably needs a better error handling
strategy, not a language change. I have done measurements in the past
and although people complain a lot about the presence of that
statement, it shows up much les
Fair enough. This would be perfect. Cheers
On Tuesday, September 5, 2017 at 5:42:26 PM UTC+10,
marti...@programmfabrik.de wrote:
>
> Dorival,
>
> I think we can celebrate already if we achieve anything with this
> discussion. Let's not ask for too much, plus let's not make it too
> complicated.
Dorival,
I think we can celebrate already if we achieve anything with this
discussion. Let's not ask for too much, plus let's not make it too
complicated.
I think your proposed "watch err", hides too much and does too little.
You can simply write (the inline code editor is broken, BTW)
func .
Hi Martin;
What about two commands "*watch*" and "*watchif*"?
The first works as the "*var*" command and the second as the "*if*" command.
"*watch*" does:
1. In a function with *error* as an output (anywhere): returns in case
the *err* declared with *watch err* (or *watch myerror*) becom
Hi Dorival,
thanks for supporting me with my idea.
And yes, after writing my post yesterday I was thinking, "watchif" or even
simply "watch".
And yes, today I am more in favor of simply *"watch"*.
And yes, we can constrain this to the context of one function (like defer),
I am ok with that.
On Monday, September 4, 2017 at 10:48:06 PM UTC+2, Tamás Gulácsi wrote:
>
> Why do you Prepare a statement if you don't reuse it? Just use a db.Exec.
Just wanted to show a pattern which I see very often in Go code. Its not a
working example, and I am not asking for improvements in that code.
I forgot (again) to say that in this case the error would just be returned.
In other words, `watch err` would just check if `err != nil` and then
return.
The other cases (test, main) would be as explained earlier (FailNow(),
Exit(1))
On Tuesday, September 5, 2017 at 10:14:16 AM UTC+10, Doriva
Hi, the `watch err` could also work in "APIs" that already return "error".
For instance:
package myapi
func First() (err error) {
watch err
err = internalFunction(1,2,3)
err = internalFunction(3,2,1)
err = internalFunction(1,3,2)
}
On Tuesday, September 5, 2017 at 4:27:20 AM U
by the way, above, I was thinking of `watch` as a counterpart of `var`...
On Tuesday, September 5, 2017 at 8:56:24 AM UTC+10, Dorival Pedroso wrote:
>
> Hi,
>
> Error management in Go is perfect!
>
> But I like the idea of `watch` (may we drop the `if`?)
>
> So, `watch` would work in the context o
Hi,
Error management in Go is perfect!
But I like the idea of `watch` (may we drop the `if`?)
So, `watch` would work in the context of a function like `defer`. However,
this would effectively become a `catcher` for errors (instead of `panics`)
within the `defer` function, right?
Also, I think
44 matches
Mail list logo
