We want the clients to be dumb. So if we are going to do something then it should probably be on the server side. Are you seeing an aggregate exception and you want both of them reported?
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
yeah I think there is a biggeri ssue we are totally not even looking at all the inner exceptions, just the first one returned by inner exception @ejsmith
inner exceptions are ok and don’t need to be turned into multiple events, but aggregate exceptions really are multiple exceptions that should be split up.
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
but suppose the leaking is stopped. and you have an AggregateException with 2 different internal exception. I think it would make most sense to have that result in 2 stacks
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.
yeah, which is why we want the clients to be dumb so that we can change the logic if we need to later without getting everyone to update their clients.
in this case we messed up the dumb part and need everyone to update. :-(
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 :)