I would start with Design Guidelines for Exceptions its short and includes DO, DO NOT and AVOID. It also gives the reasons why.
In your example case the revelvent section would be Wrapping Exceptions
And would expect it to be written this way. Note that it catches a specific exception and attempts to add information so that a more meaningful message is propagated. Also note that the inner exception is still maintained for logging purposes
//In DataLayer
try
{
XDocument xd_XmlDocument = XDocument.Load("systems.xml");
}
catch(FileNotFoundException ex)
{
throw new TransactionFileMissingException(
"Cannot Access System Information",ex);
}
UPDATE
Kanini asks is it even right to have this exception block in the Data Layer or should the checking the file be available to Business Layer.
Well first I'd like to point out that the rationale for Wrapping Exceptions is this
Consider wrapping specific exceptions
thrown from a lower layer in a more
appropriate exception, if the lower
layer exception does not make sense in
the context of the higher-layer
operation.
So if you feel that have a higher layer should know about the file at all then your data layer should look like this
//In DataLayer
XDocument xd_XmlDocument = XDocument.Load("systems.xml");
No Try No Catch.
Personally I feel that unless your data layer can do something usefull like use a default systems.xml that is an assembly resource, doing nothing or wrapping the exception is a good bet since your logging will tell you what method and what file was the problem. (throw ex
in this case or the preferred throw
does too but adds no value). This means that once identified you'll be able to fix the problem quickly.
As an asside this particular example also has the following problem in that XDocument.Load can throw four execeptions
- ArgumentNullException
- SecurityException
- FileNotFoundException
- UriFormatException
We cannot safely guarantee that the following code won't throw and FileNotFoundException, simply because it could be there when we do existence check and gone when we do load. Having that available to the business layer would not help.
if (File.Exists("systems.xml"))
XDocument.Load("systems.xml");
SecurityException is even worse because among other reasons for this being thrown if another process grabs has an exclusive file lock you'll won't get the error until you try an open it for reading because there's no File.CanIOpenThis() method. And if such a method existed you still have the same problem as with File.Exists