[feat] - Introduce Fatal/Non-Fatal File Handling Errors #3521
Conversation
pkg/handlers/handlers.go
Outdated
| @@ -351,7 +361,7 @@ func HandleFile( | |||
| // handleChunksWithError processes data and errors received from the dataErrChan channel. | |||
| // For each DataOrErr received: | |||
| // - If it contains data, the function creates a chunk based on chunkSkel and reports it through the reporter. | |||
| // - If it contains an error, the function logs the error. | |||
| // - If it contains an error, the function returns the error immediately. | |||
There was a problem hiding this comment.
This is for fatal errors, right? This comment seems like a good place to explain non-fatal errors as well. I would also like in some comment somewhere a description of what types of errors are fatal versus non-fatal - maybe in the doc comments of functions that use DataOrErr?
| } | ||
| }() | ||
|
|
||
| start := time.Now() | ||
| arReader, err := deb.LoadAr(input) | ||
| if err != nil { | ||
| ctx.Logger().Error(err, "Error loading AR file") | ||
| dataOrErrChan <- DataOrErr{ | ||
| Err: fmt.Errorf("%w: loading AR error: %v", ErrProcessingFatal, err), |
There was a problem hiding this comment.
Do we care that we "lose" the original err since we're wrapping the sentinel error?
There was a problem hiding this comment.
We would still maintain the error string though correct? Do you think we should use errors.Join here instead?
There was a problem hiding this comment.
We would still maintain the error string though correct?
Yeah
Do you think we should use errors.Join here instead?
I think it would have the same effect. It's probably better to wrap the sentinel, right?
There was a problem hiding this comment.
I believe so. We need to be able to use errors.Is to determine if it's a fatal error.
Description:
This PR addresses the third point in this comment.
Checklist:
make test-community)?make lintthis requires golangci-lint)?