it's probably 2 problems into one. 1) what happens if you have an aggregate exception, that contains an aggregate exceptoin, and the real thing is under that. 2) what happens with multiple inner exceptions
so at some point the exceptions need to be flattened, but even then you can end up with a list of them
it’s almost like we should have a plugin and when it detects an aggregate excpetion we go over each inner exception and submit it with the a copy of the context and set the error on each context and then cancel the current context so we get all inners and not the aggregate exception
@srijken but we aren’t always uisng async and await.. only if we have to await something
yeah, agreed. I think we need to change the model to allow multiple inner exceptions so that we stop losing data and then eventually have a piece server side that will split any error up that has multiple inner exceptions at the top level.
Ideally, the error model would only allow for multiple inner exceptions at the top level.
I guess that isn’t true though, eh?
I can catch an aggregateexception and then wrap it...
but if I did that… then I think at that point it is a single error because you are rethrowing it and wrapping the error.
if you call flatten and theres two inner.. does it just return the aggregate?
if that’s the case then we should call flatten on the ToErrorModel extension method as it might cut down on a lot of use cases and then only when there is two inner ones would we have to do something with it :)