Hi Hassan,
Sometime ago I mention on discord this requirement I need for an actual project I am still working on, but at that point I didn´t have so much details in mind. I am following The Standard as much as my team and I could, so now a days, we are facing with validations at coordination and orchestration services, so they are high business logic validations that involves many entities.
We are trying to collect a bunch of validation issues instead raising a concrete exception when a concrete validation fails. This way the end user could know what are the main problems related to the operation he wants to process.
Using only one Xeption for attaching data isn´t enough because not all data attached it is related to the same exception. I can´t explain it in more business functional way because it´s huge.
On Discord, you talked and took it far away than I thought. You talked about aggregating exceptions coming from multiple threads, queue or any kind of distributed system. That would be great and could be fit with my scenario, but one step at a time :D
Could we create an AggregatedXeption inherited from Xeption? My thoughts having in mind this new AggregatedXeption class are,
- Constructors
- Empty
- list or one Xeptions to be attached
- Message
- I am not sure if using innerException and Data is needed at this level, because I think this information it´s related to each attached exception.
- Would have a property list for store many Xeptions.
- Method to upsertdatalist for a particular Xeption included in it.
- ThrowIfContainsErrors when any of Xeptions included have at least one element in Data.
- Something more?
Hi Hassan,
Sometime ago I mention on discord this requirement I need for an actual project I am still working on, but at that point I didn´t have so much details in mind. I am following The Standard as much as my team and I could, so now a days, we are facing with validations at coordination and orchestration services, so they are high business logic validations that involves many entities.
We are trying to collect a bunch of validation issues instead raising a concrete exception when a concrete validation fails. This way the end user could know what are the main problems related to the operation he wants to process.
Using only one Xeption for attaching data isn´t enough because not all data attached it is related to the same exception. I can´t explain it in more business functional way because it´s huge.
On Discord, you talked and took it far away than I thought. You talked about aggregating exceptions coming from multiple threads, queue or any kind of distributed system. That would be great and could be fit with my scenario, but one step at a time :D
Could we create an AggregatedXeption inherited from Xeption? My thoughts having in mind this new AggregatedXeption class are,