Talk:Error hiding

Examples

The examples here definitely aren't Java. They looks like Delphi.

---

A real-life example of Error Hiding should be, also (C++ code):

 try
 {
   doSomething() ;
   doSomethingElse() ;
   anotherDoSomething() ;
 }
 catch(...)
 {
 }

This is the kind of code that make you want to die when you finally discover it.

The text would be : Another justification of Error Hiding is to avoid component crashing in case of failure. Despite the error, the component continues its job. The user (and the testers) never see the crash, even if some anomalies could be discovered, as the results are not those expected. As it is this code is extremely difficult to debug (and is even more in case of ested "empty try/catch" Error Hiding code), and any anomaly is extremely difficult to trace to its origin, increasing maintenance costs, only to keep up an appearance of robustness.

Another real-life, VBScript-based Error hiding:

 If doSomething() Then
   If doSomethingElse() Then
     If anotherDoSomething() Then
        anotherOtherDoSomething()
     End If
   End If
 End If

The text would be : Another implicit Error Hiding is discarding error handling altogether and using the return parameters of functions to indicate if the process succeeded (true) or not (false). The consequence is that when some error happens, it is hidden by the code (because it's error prone or simply verbose to add an Else clause) until someone notices something is amiss. A devious consequence is that when some similar code is written, but without the If/End If clauses, and is executed after the first code, the second code will fail, but no one will know the failure happened before and was hidden. Thus one can provoke the appearance of a bug months after the bug was first introduced (but hidden and thus, never discovered).

(Paercebal 16:40, 4 October 2006, GMT+1)

As no one complained/commented, added the previous examples to the Error Hiding page.

(Paercebal 15:30, 17 October 2006, GMT+1)

Links

Added link from anti-pattern. I suggest we remove the linkless template. It's a fact of life that some articles may only have one or two relevant links due to being highly specialised. Stephenbooth uk 15:54, 2 October 2006 (UTC)

The being no objections to my suggestion to remove the linkless template, I'll now remove it.--Stephenbooth uk 16:08, 8 October 2006 (UTC)

Long history.

Error hiding has been around much longer than exception-handling programming languages. It has been a problem in the C programming language since its inception, and exceptions were included in C++ to try to catch the problem (no pun intended).

There are two ways to put error hiding into a C program. One way is to generate your own error message without attempting to resolve errno:

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>

int main(int argc, char **argv)
{
   FILE *file = fopen(argv[1], "r");
   if(FILE == NULL) {
       fprintf(stderr, "%s: cannot open\n", argv[1]);
       exit(1);
   }
   /* More error-hiding code follows */
}

C code like that above is still being written today. The two ways to fix that error (under POSIX systems) are perror (which prints the error message for you) and strerror (which returns a string describing the error):

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>

int main(int argc, char** argv)
{
   FILE *file = fopen(argv[1], "r");
   if(FILE == NULL) {
#ifdef USE_PERROR
       perror(argv[1]);
#elif defined(USE_STRERROR)
       fprintf(stderr, "%s: %s\n", argv[1], strerror(errno));
#else /* Error hiding */
       fprintf(stderr, "Huh? Something's not right!\n");
#endif
       exit(1);
   }
   /* More error-hiding code follows */
}

The other way to create an error-hiding condition is by ignoring the return values of standard library functions. Programs that do this can crash just like C++ and Java programs that have empty catch blocks.

75.186.36.20 (talk) 22:39, 20 January 2008 (UTC)

When error hiding is needed

Somethimes some sort of error hiding is needed (sorry if code is incorrect I hadn't used Java for some time):

 public interface SomeInterface {
   public void someMethod () throws SomeExceptions;
 }
 public class MyList implements SomeInterface {
   public void someMethod () throws SomeExceptions {
     try {
       doSomething ();
     } catch (OtherException e) {
       throw new RuntimeException (e);
     }
   }
 }

Otherwise the Java compiler will complain about throwing exception not specified. Or about throwing more exceptions in implementation then specified in interface (which cannot be easily changed as it is for example part of JDK). Uzytkownik (talk) 19:11, 26 March 2009 (UTC)

Page rewrite and rename

I've done a major edit to this page (diff here) to try and focus it on the actual primary topic that it's trying to tackle, and make it more neutral and less opinionated. The underlying primary topic here is, imo, exception swallowing and error swallowing, and "Error hiding" is just a symptom of a particular type of error swallowing. If I search for "exception swallowing" and "error swallowing" on google, this is the first hit :P

I've tried to incorporate all the major points of the previous version, and I've updated all the code examples to be more concise about what they're trying to exemplify. I would like to add examples of best practices at some point, but ran out of steam for the day.

More importantly, I'd like to rename this page to "Error swallowing", so I'm going to make a move request to discuss that.

Thoughts? Shana (talk) 18:52, 2 May 2019 (UTC)