On Wed, Dec 7, 2022 at 4:39 AM Brian Candler wrote:
> On Tuesday, 6 December 2022 at 21:05:48 UTC dple...@google.com wrote:
>
>> I am trying to figure out if there's a good way to build a helper that
>> can be used against different sets of nested types that have a common
>> structure.
>>
>> So,
On Tue, Dec 6, 2022 at 10:29 PM hey...@gmail.com wrote:
> > sorts defined by an ordering function purely dependent on the value of
> the element
>
> Hmm, I thought the function was agnostic to what really get compared? If
> it offers two index numbers, and the return value says the one with large
On Sat, Dec 3, 2022 at 11:34 PM burak serdar wrote:
>
>
> On Sat, Dec 3, 2022 at 8:47 PM Diogo Baeder wrote:
>
>> Now, imagine this scenario: I have a web application which has to access
>> a webservice that responds with JSON payloads; These payloads are a list of
>> values, where each value is
Hi everyone,
I am trying to figure out if there's a good way to build a helper that can
be used against different sets of nested types that have a common structure.
So, for example, say there are two libraries, `lib1` and `lib2` and both
define types Foo, Bar, and Baz with:
type Foo struct { ...
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.
> >
>
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 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
> 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 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!
&
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
11 matches
Mail list logo
