Errors not very helpful for debugging

[noozo]

Trying out reactor for the first time, so take it with a grain of salt, but a couple of things i noticed when error handling:

• No easy way to know which step err'ed, as the result is usually {:error, [some error]}
• No access to stacktrace when debugging, which is annoying when debugging. For instance, i just got this ** (MatchError) no match of right hand side value: {:error, [%BadMapError{term: nil}]} and i have no clue where that happened. The only hint i get is that somewhere i tried to access a bad term inside a map.

Would it be feasible for [errors] to actually be a map or error struct, for instance, with %{errors: errors, stacktrace: stacktrace, ...}, or at least provide that as a 3rd element of the error tuple (which sucks, i know, but would help debugging a ton)?

[jimsynz]

You're right. I was in a hurry to get back onto some client work, so I didn't really think this part through as much as I'd like. I'm interested in what you think the ideal failure result would look like? Maybe @zachdaniel has some ideas too?

[zachdaniel]

We've talked about standardizing some of the concepts from Ash.Error into its own package, and then using it in both places. The main idea is to use "Error classes" and standardized exceptions that capture the stacktrace at the place they were created. We'd have to start somewhere practical for this. We could extract the basics of that system out (which we decided to call splode IIRC) and include a metadata key where the step that generated it could be included.

[jimsynz]

Hopefully the changes in #97 should improve this situation greatly.