In this lesson, we're going to take a deeper look into how we can use channels, such as restricting their functions to either sending or receiving, as well as making use of the select keyword so that our code can wait to receive from multiple channels at the same time.

---

Refactoring to a countFiles Function

To begin, let's first create a new function called countFiles, which will take a parameter called fileNames, which will be a slice of string. Then for the return values of this function, let's go ahead and return a channel of fileCountsResult.

However, rather than returning a full-fledged channel, which can be both written to and read from, let's instead constrain this return result so we can only read from this channel, which we can do as follows:

func countFiles(fileNames []string) <-chan fileCountsResult

This syntax means this is a channel that can only be read from.

For example:

rch := countFiles([]string{})
rch <- value // ❌ cannot send to receive-only channel

This is useful to communicate with the caller of this function that data will be sent on it, but they shouldn't send data to it.

---

Implementing the Function

ch := make(chan fileCountsResult)
return ch

We range over each of the filenames passed in, get the counts, and publish it:

go func() {
    res := fileCountsResult{
        Count:    count,
        FileName: filename,
    }
    ch <- res
}()

Add a sync.WaitGroup, call wg.Add(len(filenames)), and use:

defer wg.Done()

At the end, close the channel using:

go func() {
    wg.Wait()
    close(ch)
}()

Now we can call countFiles from main, pass in the filenames, and range over the results.

---

Handling Errors

If I pass in a file name that doesn't exist, we're no longer handling the error. To fix that, we can do the usual:

if err != nil {
    fmt.Fprintln(os.Stderr, "counter:", err)
    didError = true
    continue
}

But that didError flag is no longer being set.

---

Option 1: Add error to the result struct

type fileCountsResult struct {
    Count    counter.Counts
    FileName string
    Err      error
}

Then:

res := fileCountsResult{Err: err}

In main:

if res.Err != nil {
    didError = true
    fmt.Fprintln(os.Stderr, "counter:", res.Err)
    continue
}

---

Option 2: Use a second error channel

Change the return type:

func countFiles(...) (<-chan fileCountsResult, <-chan error)

Then:

errCh := make(chan error)

Write to it when there's an error:

errCh <- err

Close it when done.

In main, you'd capture both:

rch, errCh := countFiles(files)

---

Buffered Channels vs Unbuffered

You could make errCh buffered:

errCh := make(chan error, len(files))

That works, but it’s a bit of a cheat. A better solution is using select.

---

Using select to Read from Multiple Channels

You can select over multiple channels:

select {
case res := <-ch1:
    fmt.Println("Channel 1 received", res)
case res := <-ch2:
    fmt.Println("Channel 2 received", res)
}

If both are ready, one is selected at random.

---

Example with Select

loop:
for {
    select {
    case res, open := <-ch:
        if !open {
            break loop
        }
        totals.Add(res.Count)
        res.Count.Print(res.FileName, tw)

    case err, open := <-errCh:
        if !open {
            break loop
        }
        didError = true
        fmt.Fprintln(os.Stderr, "counter:", err)
    }
}

---

Alternative: Nil Out Closed Channels

Instead of using a break loop, we can do:

if !open {
    ch = nil
}

Do the same for errCh. When both channels are nil, break out:

if ch == nil && errCh == nil {
    break
}

This works because Go ignores nil channels inside a select.

---

Summary

With that, we've managed to take a look at how we can handle multiple channels at the same time, being able to iterate over each of them until they are both closed.

Whilst this approach works, personally, I find using multiple channels to be a little more complex, and instead I much prefer to just parse in the error, if it exists, inside of the result struct. Personally, I find it makes the code a little bit easier to see what's going on, and it's a little bit more simple to reason about.

So in my case, I'm going to go back to that previous error handling. However, each approach is going to come down to your own personal preferences, so choose whichever one you like.

Either way, no matter which approach you prefer, once you've made the changes, go ahead and commit your code as always, and we'll move on to our next lesson.