c# - How should interface implementations handle unexpected internal exceptions of types callers might expect? -

c# - How should interface implementations handle unexpected internal exceptions of types callers might expect? -

if class implements interface, how should handle situations eitherin execution of method or property, internal error occurs of type caller might reasonably expecting handle, caller perhaps should not. example, idictionary.add internally yields argumentexception under circumstances imply dictionary corrupt, not imply bad rest of system? or imply corrupted beyond dictionary? caller may expecting grab , handle fact duplicate key exists in dictionary, since in cases exception may vexing (e.g. same code may used dictionary that's not accessed other threads , concurrentdictionary is, , semantics workable if effort add together duplicate record caused clean failure). letting argumentexception percolate lead caller believe dictionary in same state if add together never occurred, dangerous, throwing other exception type seem confusing. in execution of method or property, exception occurs caller maybe should or shouldn't handle, , definition of interface doesn't provide hint even-remotely-related exception might occur. example, suppose goes wrong in evaluation of ienumerator, either implying (1) enumerator got corrupted (possibly unexpected action on thread) retrying enumeration might succeed; (2) enumerable object corrupted or unusable, else in scheme okay (e.g. lazily-evaluated file parsing routine nail invalid record); (3) beyond enumerable object has been corrupted. ienumerable has 1 defined exception can throw, caller may want vary action based upon 'severity' of exception. if had druthers, scheme define types retryablefailureexception, cleanfailureexception, objectcorruptfailureexception, , interfaces allowed throw or derivatives thereof. since that's not case, how should 1 handle interfaces, either view of interface or caller?

btw, 1 pattern i've not seen implemented, seem useful, methods take delegate parameter executed in case method fails in way cause "try" method homecoming false. such delegate, supplied caller, not throw exception recipient know for, set flag otherwise available caller. caller know exception beingness caught indeed 1 expected.

an interface's job define members (and signatures) class must have, not how should implemented. hence allow exception bubble stack. if want define contract , command of implementation (such error handling) should create base of operations class (i lean towards mustinherit/abstract class in situation) mustoverride methods base of operations class calls methods (in situation in seek grab can special error handling).

c# .net vb.net exception interface