feat: Add a SliceMapE function for handle errors and add unit tests

[WillardHu]

Overview

Sometimes, errors can occur when processing data transformations. The SliceMap function is relatively weak in error handling. We've add a SliceMapE function to handle these scenarios and added unit tests for both functions.

[vMaroon]

Hi @WillardHu - I think abstractions are justified by use mostly. While this sounds reasonable, do you intend to propose using it instead of SliceMap in some instances?

[WillardHu]

The places where SliceMap is used now seem to be simple object conversions, but if different types of conversions are encountered in the future, an error handling may be required, such as string to constant enumeration, string to integer, etc.

For Example:

type Status string
const (
    StatusTrue Status = "True"
    StatusFalse Status = "False"
)

func Test() {
    items = []string{"True", "T"}
    statusItems, err := SliceMapE(items, func(s string)(Status, error) {
        switch s {
        case string(StatusTrue):
            return StatusTrue
        case string(StatusFalse):
            return StatusFalse
        default:
            return "", errors.New("...")
        }
    })
}

However, I think SliceMap is also necessary. If the conversion does not require error handling, there is no need to write a meaningless error handling.

func Test() {
    items = []int{1, 2}
    intItems, err := SliceMapE(items, func(s int)(string, error) {
        return strconv.Itoa(1), nil
    })
    if err != nil {...} // Meaningless error handling
}

[vMaroon]

Like I said in the other comment - in general abstractions should exist only when used, but I think this one may come in handy at some point or another. The test is good - thank you @WillardHu!

[vMaroon]

/lgtm
/approve