How do I tell where in a chain of Bind calls an exception was thrown?

[MrYossu]

Suppose I have a set of methods, each of which return a TryAsync<T>, and I want to chain them together...

await DoSomething()
  .Bind(x => DoSomethingElse(x))
  .Bind(y => DoSomethingDifferent(y))
  // Maybe more methods called with Bind here
  .Match(z = > {
    // Do whatever we do on success
  },
  ex => {
    // Do whatever we do on failure
  });

This is all fine, but in the second lambda for Match, how do I know where the exception was thrown? Given that the various methods being called can throw a variety of exceptions, I can't rely on anticipating all possible exception types, and acting according to that, especially as more than one method might raise the same type of exception.

The reason this is important is that I need to know where in the chain things broke, so I can retry the bits that broke, without repeating the bits that worked.

For example (ignoring the fact that I'm dealing with side-effects in my code, which I know I shouldn't be doing, but I'm still working all this out), then it could be that the first method generates a document and saves it to the database, and the second emails the document to someone. If the creation failed, I need to do the whole process again. However, if the creation succeeded, but the emailing failed, I don't want to generate a duplicate document, I just want to try emailing again.

Anyone any suggestions. Thanks.

[sircuri]

You perceive the document generator and mail function as a single operation. I think you need to split that in 2 distinct operations and each operation is responsible for its own resiliency. I think the retry mechanism should be in the mail operation and not at the end of the chain in your match/ex branch.

[MrYossu]

@sircuri I'm not sure I think of them as a single operation, more as two operations that happen one after the other, which is why I was binding them together. That was only an example, it's not the only case where I would have this question.

The main point of my question wasn't about the retry mechanism itself, more about detecting where the error occurred. Yes, splitting them into two separate operations would answer that as well, but imagine this was a workflow where it was a single operation, I'd still want to know which part of it failed.

Thanks for the reply. Any further comments?

[louthy]

@MrYossu Maybe I'm missing something, but can't you just look at the StackTrace property of the Exception?

[MrYossu]

@louthy Thanks for the suggestion. I guess I can do it that way, but I was hoping for something a little neater.

Is this the only way of doing it? Thanks again.

[sircuri]

I cannot really pinpoint where your view on this issue feels wrong. You want to fire a chain of events and if something fails you want to restart the chain. But at that point you want start at a specific step. Maybe add some kind of transaction identifier to the chain, so each step knows if it has already performed that step and can skip it?

[MrYossu]

I cannot really pinpoint where your view on this issue feels wrong. You want to fire a chain of events and if something fails you want to restart the chain. But at that point you want start at a specific step.

No, this is what I tried to clarify with my previous post. The issue of restarting is really a separate one, my main question here is knowing where the chain failed, mainly for reporting purposes. Restarting/resuming the chain was a side-issue that isn't really the main point here.

Maybe add some kind of transaction identifier to the chain, so each step knows if it has already performed that step and can skip it?

Could do I guess. I was hoping there was a neater (ie built-in) way, like the way the exception gets passed along until the end of the chain.

Thanks again.