On Oct 25, 2022, at 2:28 PM, 'Daniel Lepage' via golang-nuts
wrote:
>
> In contrast, the modern Go version buries the "normal" flow in a pile of
> error handling, and IMO is a lot harder to follow:
>
> foo, err := Foo()
> if err != nil {
> return fmt.Errorf("enforcing foo limit: %w", err)
On Mon, Oct 24, 2022 at 7:18 PM Ian Lance Taylor wrote:
> On Sun, Oct 23, 2022 at 9:31 PM 'Daniel Lepage' via golang-nuts
> wrote:
>
> ...
>
>
> > 3. Streamlining shouldn't only apply to error handling that terminates
> the function.
> >
> > Unlike panics, errors are values, and should be treate
On Mon, Oct 24, 2022, 9:03 PM robert engels wrote:
> Totally understandable, but then I think the Go team should also drop any
> proposals related to “improved error handling” - because you are going to
> arrive back where you started - maybe with the a slightly different syntax
> and that hardly
Totally understandable, but then I think the Go team should also drop any
proposals related to “improved error handling” - because you are going to
arrive back where you started - maybe with the a slightly different syntax and
that hardly seems worth the effort. Great engineering is built by sta
On Mon, Oct 24, 2022 at 8:49 PM Robert Engels wrote:
>
> I’ve read that many times and I don’t believe it holds much water. Even the
> example cited about handling the inability to open a file - the function
> can’t handle this because it does not know the intent which leads to the
>
> If err !=
I’ve read that many times and I don’t believe it holds much water. Even the
example cited about handling the inability to open a file - the function can’t
handle this because it does not know the intent which leads to the
If err != nil {
return err
}
boilerplate. This is exactly what checke
On Mon, Oct 24, 2022 at 5:57 PM Robert Engels wrote:
>
> But that highlights the value of exceptions - the non error path is very
> clean. For example when writing a file - it often doesn’t matter the reason
> it failed within the write function - could be an invalid path, illegal file
> name ,
But that highlights the value of exceptions - the non error path is very clean.
For example when writing a file - it often doesn’t matter the reason it failed
within the write function - could be an invalid path, illegal file name , out
of disk space. If the code is properly decomposed that fun
On Sun, Oct 23, 2022 at 9:31 PM 'Daniel Lepage' via golang-nuts
wrote:
...
> 3. Streamlining shouldn't only apply to error handling that terminates the
> function.
>
> Unlike panics, errors are values, and should be treated as such, which means
> that the calling function should be able to de
ISTM that a lot of your arguments boil down to throwing two disparate
things into the same pot:
1. Detecting and handling failure modes outside the current process, which
have to be expected and should be dealt with gracefully by a correct
program.
2. Limitations of Go's type system, which result i
On Sun, Oct 23, 2022 at 1:08 AM Brian Candler wrote:
> > And I agree that the above function is much easier to read and much
> faster to write than the first version! But now I'm raising unchecked
> exceptions instead of handling errors properly.
>
> However you're not "raising an unchecked excep
On Saturday, 22 October 2022 at 22:25:16 UTC+2 dple...@google.com wrote:
> that the above function is much easier to read and much faster to write
True but in my opinion not relevant because:
1. Time to write a function is almost negligible compare to its
time needed for maintenance, rewrites, u
> And I agree that the above function is much easier to read and much
faster to write than the first version! But now I'm raising unchecked
exceptions instead of handling errors properly.
However you're not "raising an unchecked exception"; you're panicking,
which is something different. Go doe
On Fri, Oct 21, 2022 at 12:30 PM Daniel Lepage wrote:
>
> > In that issue there was considerable resistance to having flow of control
> > change as part of an expression. No other part of Go works that way: flow
> > of control change is always a keyword, or a call to panic which can only
> > oc
On Fri, Oct 21, 2022 at 5:57 PM Andrew Harris wrote:
> Comparing 'panic' and 't.Fatal', they are similar in that there's no
> notion of recovering and making further progress, they abruptly terminate
> the process. Still, a wonky thing to say is that a 't.Fatal' call is
> completely legitimate as
On Fri, Oct 21, 2022 at 5:16 PM Robert Engels wrote:
> Unchecked exceptions in Java denote programming errors or critical
> unrecoverable errors.
>
Yes, that's exactly what I'm saying. This is what panics are used for in
Go; if you have an error that is recoverable you ought to be returning an
e
Comparing 'panic' and 't.Fatal', they are similar in that there's no notion
of recovering and making further progress, they abruptly terminate the
process. Still, a wonky thing to say is that a 't.Fatal' call is completely
legitimate as a form of "checked"-style error handling. It will log what
Unchecked exceptions in Java denote programming errors or critical
unrecoverable errors.
If these are being trapped/handled it is indicative of a system with design
errors.
(That being said, some programming errors can be ignored/handled at the request
level - indicating that the chance any
> That aspect of this idea seems similar to the try proposal (
https://go.dev/issue/32437).
Yes, I read over that proposal and the comments; it seemed like the biggest
objections were:
1. handle() is very similar to defer/recover but not quite the same, which
could be confusing (e.g. that a defer(
On Thu, Oct 20, 2022 at 9:52 PM Daniel Lepage wrote:
>
> Sorry, I should have been clearer - what I am proposing is both try/handle
> blocks and a `check` expression that triggers the handler.
Sorry, I did miss the "check". That aspect of this idea seems similar
to the try proposal (https://go.
On Thu, Oct 20, 2022 at 5:36 PM Ian Lance Taylor wrote:
> On Thu, Oct 20, 2022 at 2:14 PM 'Daniel Lepage' via golang-nuts
> wrote:
> >
> > I'm not sure if this is the right forum to ask this question - please
> let me know if there's somewhere better!
> >
> > I'm wondering why most of the Go 2 e
On Thu, Oct 20, 2022 at 2:14 PM 'Daniel Lepage' via golang-nuts
wrote:
>
> I'm not sure if this is the right forum to ask this question - please let me
> know if there's somewhere better!
>
> I'm wondering why most of the Go 2 error handling proposals I've seen are
> intent on not letting a func
Hi all,
I'm not sure if this is the right forum to ask this question - please let
me know if there's somewhere better!
I'm wondering why most of the Go 2 error handling proposals I've seen are
intent on not letting a function continue after detecting an error - this
seems weird to me, since we alr
23 matches
Mail list logo
