Closed anoordover closed 2 years ago
I also thought about this but it would enable other people to create a new exception class and a translator without contributing back to the project
Also, I'm not sure how to extend ExecuteSqlInterpolatedAsync
so that it throws the translated exception instead of DbException
I think you cannot but my issue is that it would be nice when a user of your packages can also choose to just use the DbException translation inside their own catch-block. These parts of your packages could than be used in other scenarios, e.g. EF6 and raw-sql.
The current implementation uses the EF StateManager to intercept SaveChanges and SaveChangesAsync. I think it would be nice to provide an entry-point to use the different ExceptionProcessorStateManagers as a translator for a DbException so that a user can also use these translators in their own catch-block to translate a DbException or a DbUpdateException to specific exception. These translators can than be used in a catch-block when executing e.g. ExecuteSqlInterpolatedAsync. When translating from a DbException these translators don't need a dependency on any specific EF-version.