Error hiding

Error hiding is an anti-pattern, in computer programming. The programmer hides error messages by overriding them with exception handling. The result of this is that user may never know what really went wrong.

Example:

 try
   ImportFile(filename);
 except
   // a exception with almost no information
   raise Exception.Create('import failed'); 
 end;

This code fragment attempts to open a file and read it into memory. If it fails (for whatever reason) the user only gets a message telling them that the import failed, not why or indeed which file failed to import.

 // better approach
 try
   ImportFile(filename);
 except
   on E:Exception do
   begin
     // build a informative message
     E.Message := 'Import of file <'+filename+'> failed.'+#13#10 +
       E.Message;
     // re-raise the exception
     raise;  
   end;
 end;

In this example the user at least gets a message that tells them which file failed to import, this gives them a start at diagnosing the problem. A more complete solution would include additional information on why the import failed (e.g. "File does not exist", "File appears to be damaged", "Do not have permission to access this file" &c).

Another example is the fact that accessing the contents of a file that does not exist in Java version 1.3 or older would result in an IOException without any reference to the missing file.

Error hiding is a bane of support engineers' jobs as it often delays the resolution of the problem by hiding information needed to identify what is going wrong. A common arguement for error hiding is the desire to hide complexity from the user. Frequently best practice is to raise an exception to the user to hide a complex error message but to save the full error message to an error log which a support engineer can access to resolve the problem.