[go: nahoru, domu]

Jump to content

Error hiding: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
JECompton (talk | contribs)
Stub-sorting. You can help!
No edit summary
Line 1: Line 1:

{{context}}
'''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.
'''Error hiding''' is an [[anti-pattern]], in [[computer programming]]. The programmer hides error messages by overriding them with [[exception handling]]. As a result of this the root error message is hidden from the user (hence 'Error Hiding') and so they will not be told what the actual error. 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.


''Example:''
''Example:''
Line 26: Line 28:
'''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).
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) and write the information to a log file, possibly (for very complex or enterprise level applications) also generating extra 'trace' files containing detailed records of the state of the application when the error occured.


Another example is the fact that accessing the contents of a file that does not exist in [[Java programming language|Java]] version 1.3 or older would result in an <code>IOException</code> without any reference to the missing file.
Sometimes Error Hiding is a valid activity, for example accessing the contents of a file that does not exist in [[Java programming language|Java]] version 1.3 or older would result in an <code>IOException</code> message without any reference to the missing file. In this case is would be sensible to hide the error and raise an exception based on what the application was trying to do at the time, giving what extra information can be obtained.


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.
{{comp-prog-stub}}
{{comp-prog-stub}}
[[Category:Anti-patterns]]
[[Category:Anti-patterns]]

Revision as of 17:39, 1 August 2006

Error hiding is an anti-pattern, in computer programming. The programmer hides error messages by overriding them with exception handling. As a result of this the root error message is hidden from the user (hence 'Error Hiding') and so they will not be told what the actual error. 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.

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) and write the information to a log file, possibly (for very complex or enterprise level applications) also generating extra 'trace' files containing detailed records of the state of the application when the error occured.

Sometimes Error Hiding is a valid activity, for example accessing the contents of a file that does not exist in Java version 1.3 or older would result in an IOException message without any reference to the missing file. In this case is would be sensible to hide the error and raise an exception based on what the application was trying to do at the time, giving what extra information can be obtained.


Template:Comp-prog-stub