by Eugen Gez
Version 1 (September 30, 2018)
Download (158 downloads)
An example of how cascaded error handling should be and how a workaround could look like now.
It looks like there's no cascading while error handling.
If you place two "failure catch" blocks after each other, then only the last one proceeds trough the fail path if an error occurs. If the retry count is reached, the fiber is simply stopped without propagating the error to the previous "failure catch" block.
I think, there must be a possibility to let the last "failure catch" block fail (throwing an error) if it's retry count is reached.
It must be possible to let an operation completely fail (and maybe go another way) if a sub-operation fails and cannot recover.
This way we can better structure the error handling and avoid connecting multiple "failure catch" blocks of each sub-operation to the same alternative flow where only the "failure catch" block of main operation will do the same job.
5 stars | 0 | |
4 stars | 1 | |
3 stars | 0 | |
2 stars | 0 | |
1 star | 0 | |
Reports | 1 |
Rate and review within the app in the Community section.