>On Friday 30 August 2024 at 12:05:33 UTC+2 Christoph Berger wrote:
>Opinionated answer: If a container type cannot iterate over its elements
without fail, I would refrain from trying to build a standard iterator for
this container type. You'd be shoehorning a
>iterator that can fail into the ite
Hi,
Java is certainly not Go, now we have a great simplification to develop
code, but you can clarify the context for making a decision in the
description of the ValueListHandler J2EE pattern.
Regards,
пятница, 6 сентября 2024 г. в 02:11:39 UTC+3, cpasmaboiteaspam:
> Hello,
>
> I would defini
Hello,
I would definitely use *func Iter(ctx, data) iter.Seq2[T, error]*
Because its standard and it is easy for the end user to build a bridge to a
scanner like API
such as struct[T any]{ All() iter.Seq[T]; Err() error },
or* anything else*.
Because i have make the *trailing error return* a *
I like this approach.
- bufio.Scanner-style errors are a known pattern from the stdlib
- The approach keeps the key and value params free for their intended use
- It doesn't require nested iter seqs
- It is compatible with range loops
Made some sample code as PoC -> https://go.dev/pla
I would likely go with something similar to how you would currently use
bufio.Scanner but comine the use of .Scan() and .Text() as Range()
```go
iter := rows.Iter(ctx)
for obj := iter.Range {
// do something with obj
}
if err := iter.Err(); err != nil {
return err
}
```
Or if rows can
I like:
```go
func Iter(ctx, data) (iter.Seq[Object], *error)
```
There are some examples of this pattern in
https://pkg.go.dev/github.com/bobg/seqs
Cheers,
- Bob
On Thursday, August 29, 2024 at 5:41:47 AM UTC-7 Dmitriy P wrote:
> What is the best way to handle errors with iterators?
>
> How t
Opinionated answer: If a container type cannot iterate over its elements
without fail, I would refrain from trying to build a standard iterator for
this container type. You'd be shoehorning an iterator that can fail into
the iter API that is not designed for dealing with errors.
Putting half-w