How to handle recoverable errors in multi-step computation?
Dear haskellers, I have a multi-step computation. The steps are predefined, but users can choose which steps to execute (something like a recipe). Here is an example recipe: Step 1 - Get data from network (multiple HTTP calls) and put into a list Step 2 - Process the data (e.g. average, sum, median, etc.) Step 3 - Persist result to database Sometimes, Step 1 can fail for some of the HTTP calls. When this happens, Step 2 should continue as much as possible using whatever data that has been retrieved, but somehow indicate that an error has occurred and the result is partial. Q1: What is the idiomatic way of achieving this? Using throwError in Control.Monad.Except aborts the computation, which isn't what I want. Q2: (General software design) Furthermore, where should the error be logged? Logging it in both Step 1 and 2 preserves modularity for each of the steps, unfortunately it would result in duplicate error messages. What is the best practice for this? Regards, Hon
hello Hon, you could: Q1) return Either Partial Result from each step that may partially fail Q2) Partial type may include (tag, level) where tag is generated by the function where it first happened, level is incremented in each caller function (where the "error" bubbled up/propagated). Log fails in every steps. Tags would let you link errors, levels would hint at the order in which the error bubbled up. this may not be the best practice. Just a possibility.
It sounds like you want the Validation applicative functor. See e.g. https://ro-che.info/articles/2015-05-02-smarter-validation On 02/06/2016 04:58 AM, Lian Hung Hon wrote:
Dear haskellers,
I have a multi-step computation. The steps are predefined, but users can choose which steps to execute (something like a recipe). Here is an example recipe:
Step 1 - Get data from network (multiple HTTP calls) and put into a list Step 2 - Process the data (e.g. average, sum, median, etc.) Step 3 - Persist result to database
Sometimes, Step 1 can fail for some of the HTTP calls. When this happens, Step 2 should continue as much as possible using whatever data that has been retrieved, but somehow indicate that an error has occurred and the result is partial.
Q1: What is the idiomatic way of achieving this? Using throwError in Control.Monad.Except aborts the computation, which isn't what I want.
Q2: (General software design) Furthermore, where should the error be logged? Logging it in both Step 1 and 2 preserves modularity for each of the steps, unfortunately it would result in duplicate error messages. What is the best practice for this?
Regards, Hon
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
You might also want to check out Chronicle monad in these package:
https://hackage.haskell.org/package/these-0.6.2.1/docs/Control-Monad-Chronic...
Kind regards,
Nick
On Sat, 6 Feb 2016 at 11:58, Roman Cheplyaka
It sounds like you want the Validation applicative functor. See e.g. https://ro-che.info/articles/2015-05-02-smarter-validation
On 02/06/2016 04:58 AM, Lian Hung Hon wrote:
Dear haskellers,
I have a multi-step computation. The steps are predefined, but users can choose which steps to execute (something like a recipe). Here is an example recipe:
Step 1 - Get data from network (multiple HTTP calls) and put into a list Step 2 - Process the data (e.g. average, sum, median, etc.) Step 3 - Persist result to database
Sometimes, Step 1 can fail for some of the HTTP calls. When this happens, Step 2 should continue as much as possible using whatever data that has been retrieved, but somehow indicate that an error has occurred and the result is partial.
Q1: What is the idiomatic way of achieving this? Using throwError in Control.Monad.Except aborts the computation, which isn't what I want.
Q2: (General software design) Furthermore, where should the error be logged? Logging it in both Step 1 and 2 preserves modularity for each of the steps, unfortunately it would result in duplicate error messages. What is the best practice for this?
Regards, Hon
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
participants (4)
-
Imants Cekusins -
Lian Hung Hon -
Nickolay Kudasov -
Roman Cheplyaka