Current error handling implementation returns EHttpStatus or EApiErrors. This is a valid approach. However, package users may want to define additional error handling. For example:
report which user caused error on API errors
report which proxy caused error on 407 "Proxy Authentication Required"
Custom error handling would be beneficial when using multiple accounts/proxies. As is now, whenever an account or proxy breaks, all defined configs must be checked manually to determine the cause of the problem. Alternatively, it is possible to try/catch on each fetch, but this introduces a lot of boilerplate code.
The problem can be solved by letting the user define custom error handler. The handler may be passed to FetcherService via RettiwtConfig or via new RettwitErrorHandler optional parameter, like so:
Current error handling implementation returns EHttpStatus or EApiErrors. This is a valid approach. However, package users may want to define additional error handling. For example:
Custom error handling would be beneficial when using multiple accounts/proxies. As is now, whenever an account or proxy breaks, all defined configs must be checked manually to determine the cause of the problem. Alternatively, it is possible to try/catch on each fetch, but this introduces a lot of boilerplate code.
The problem can be solved by letting the user define custom error handler. The handler may be passed to FetcherService via RettiwtConfig or via new RettwitErrorHandler optional parameter, like so:
Then interface and error handler can be defined:
@Rishikant181, what do you think?