Avoid Using panic for Error Handling

[oswaldom-code]

Description

Currently, some functions use panic to handle errors. While panic is useful for unrecoverable situations, it is generally not idiomatic in Go for handling expected errors. This approach can be problematic because:

1. It disrupts the normal control flow of the application.
2. It forces users to wrap function calls with defer/recover, making error handling more complex.
3. It reduces flexibility, as users might want to handle errors in different ways instead of being forced into a panic.
4. The Go standard library follows a convention of returning errors instead of panicking, except for cases where failure is truly exceptional.

Proposed Solution

• Replace panic with proper error handling by returning error values.

I’d be happy to submit a PR addressing this issue by refactoring the affected functions. Please let me know if this aligns with the project’s philosophy.

Command executed to detect the use of panic:

grep -r -n --exclude='*_test.go' --exclude='*.md' 'panic' . | sed 's|//.*||' | grep -vE '^\s*$'

Result:

➜  lo git:(master) grep -r -n --exclude='*_test.go' --exclude='*.md' 'panic' . | sed 's|//.*||' | grep -vE '^\s*$'
./slice.go:209:         panic("Second parameter must be greater than 0")
./slice.go:610:
./slice.go:633:
./errors.go:31:
./errors.go:45:                 panic(message)
./errors.go:51:                 panic(message + ": " + e.Error())
./errors.go:53:                 panic(e.Error())
./errors.go:57:         panic("must: invalid err type '" + reflect.TypeOf(err).Name() + "', should either be a bool or an error")
./errors.go:62:
./errors.go:311:
./string.go:35:         panic("lo.RandomString: Size parameter must be greater than 0")
./string.go:38:         panic("lo.RandomString: Charset parameter must not be empty")
./string.go:119:                panic("lo.ChunkString: Size parameter must be greater than 0")
./map.go:254:           panic("The chunk size must be greater than 0")
./concurrency.go:22:            panic("unexpected arguments")

[Sedose]

Regarding

./slice.go:209: panic("Second parameter must be greater than 0")

If this library treats a non-positive size as a hard, programmer‐usage bug, then using panic is actually an appropriate choice in Go. Go’s standard library panics in similar “programming error” scenarios.

This indicates that the caller has misused the function in a way that can’t produce any meaningful result. In other words, there’s no way for the calling code to handle a size of zero or less to produce valid chunks, so the best course is to force a failure so the caller sees the mistake immediately. This is actually the case of "unrecoverable situation".

If non‐positive size is treated as categorically invalid usage, then a panic is a perfectly valid and idiomatic way to signal that the code has hit a fundamental, unrecoverable precondition failure