architecture - exception handling design -

in current project there components / libs designed adapters.
example 1 adapter encapsulates io access file system.

in actual exception handling design adapter has throw specific exceptions filesystemfilenotfoundexception.
adapter specific exceptions have derived adapter base exception.

the main reason developer has a relativ way catch adapter specific exception.

sometimes base exceptions provide additional information, in case of io adapter source file , target file property holds full path , file name of each file.

the main application has 3 own base exception of 3 different scenarios.

there several adapter called main application.
each adapter need own exception mapping logic in main application.
map adapter application exception type, work on additional exception information , on.

the following code needed map source target exception

        var map = new dictionary<type, type>()         { typeof(filealreadyexiststechnicalexception) } };          var filesystemadapterexception = ex filesystemadapterbaseexception;         if (filesystemadapterexception != null)         {             var exception = mapping in map                             mapping.key.equals(filesystemadapterexception.gettype())                             select mapping.value;              var basetechnicalexception = (technicalexception)activator.createinstance(exception.single());              basetechnicalexception.addplaceholderentry(exceptionplaceholderconstants.file, filesystemadapterexception.sourcefile);              resultexception = basetechnicalexception;         }          return resultexception; 

1.) design?
2.) how can mapping generalized ?
first thought of automapper, can give me possibility work on additional information?

your first questions was: "is design?". it's hard answer without going more details , understanding big picture. given provided have answer: "no". it's not design because it's incredibly complicated. seems me exception handling more involved actual system it's built. remember, i'm guessing. if i'm developer has support code base have 1 question: "why???". why exception handling has straightforward possible, wrapped paradigm of own?

you have adapters , corresponding exception classes , want preserve original exceptions. beauty exceptions chained (at least in java/.net worlds). in java have exception.getcause(), in .net - exception.innerexception. in opinion, it's need, , other people expect, handle , propagate exceptions between different layers of abstraction.