improv(batch): improve errors

[dreamorosi]

Description of your changes

This PR improves the implementation of the errors thrown by the Batch Processing utility as well as some of the outputs by streamlining the log emitted or adding names to the errors and establishing a hierarchy.

Most of the errors were either using a generic Error class and/or expecting the caller to do the heavy-lifting of formatting the message. This PR introduces errors classes that are thrown in specific cases, which will help customers with try/catch logic.

Additionally, in most cases the errors are now performing the formatting or including the message/name that defines them without the caller having to specify it.

Related issues, RFCs

Issue number: closes #1647

Checklist

• My changes meet the tenets criteria
• I have performed a self-review of my own code
• I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my change is effective and works
• The PR title follows the conventional commit semantics

Breaking change checklist

Is it a breaking change?: NO

• I have documented the migration process
• I have added, implemented necessary warnings (if it can live side by side)

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[erikayao93]

I like the idea of the errors here, and I had some time to check in, so I thought I'd leave some comments! Feel free to let me know your thoughts.

[erikayao93]

Would we want the error thrown in the BatchProcessor here to be as this BatchProcessingError instead of just Error, now that we have this?

[dreamorosi]

Indeed, very good catch. Updated in the latest commit.

[erikayao93]

Do we want a test or two to check the contents of errors?
Same for the SQS FIFO processor class, we don't have anything that actually checks the error name, message, etc, of the error thrown.

[dreamorosi]

I think it's a good point, I have updated the SQSFifo & other tests to at least test the error type.

For now we'll leave the Error contents out of the tests to avoid making them too rigid.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[erikayao93]

Do we want to update the error passed to the failure handler here (and in AsyncBatchProcessor) to be the BatchProcessingError as well?

And potentially add tests for the error type checking like with the SqsFifoPartialProcessor tests if we add the typing here?

[dreamorosi]

I think we should leave Error there because that's the type expected by failureHandler and we want that method to stay generic so that customers creating their own partial processor can pass any type of error. Making the error more strict would force them to have to subclass our own error class.