>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 happening here?),
at best the code seems equivalent to the current code, to me. There is a
function call, a conditional to check for error and then some error
handling. When skimming that code, it would look pretty much identical to
the current idiom.
I guess I should have explained it more clearly.
I was proposing that there should be a language construct called errors.
This would be an array. As exceptions are raised the program would push the
errors into this array. At any time you could examine the array to see if
there were errors and if so what they were. When I said "err.pop" I was
indicating that the program would remove the latest error from the stack to
examine it and act on it.
This would eliminate a lot of boilerplate but conceptually be the same kind
of error handling. Instead of returning a value, err pair you simply return
the value or you raise an exception. The called can check if an error was
raised by calling some method to indicate whether or not the errors array
is empty.
For example
x = someMethod()
// if there was an error in there it would populate the array but we don't
have to explicitly receive the err in the return.
ifErr {
// fetch the error
err = errors.pop()
something()
}
Something like that.
I also realize that sometimes you may want to halt the app on errors so
there should be a way to bypass this by some kind of declaration.
--
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.
