2

For example, imagine we are going to read from XML files and read to a txt files. How can I know what are all possible exceptions for these actions and then add them into catch clauses, so my program will never unexpectedly interrupts? How is the way in a general case?

Edit (Response to the duplication): I would like to know what are each individual exception for an action rather catching Exception so I can react to each of them differently.

lonesome
  • 2,503
  • 6
  • 35
  • 61
  • 2
    this: http://stackoverflow.com/questions/1075895/how-can-i-catch-all-the-exceptions-that-will-be-thrown-through-reading-and-writi – Dominik Jan 05 '16 at 12:37
  • If the operation involved in reading have checked exceptions,then you will have to handle them to resolve compile time issues.you can add them in catch blocks and at last you can have Exception.. – RockAndRoll Jan 05 '16 at 12:42
  • @PrinceManiGupta but there might be different type of exception such as if the string is null, or the file does not exist etc. So I would like to perform different action for different exception. – lonesome Jan 05 '16 at 12:43
  • 1
    You want to handle runtime exceptions i.e NullPointerException too?? – RockAndRoll Jan 05 '16 at 12:49
  • 1
    @PrinceManiGupta I want to handle any possible exception that may cause my program to be interrupted (in general), because I want to run it and leave it unattended so it will stop when it reaches the ending point. Something like this. – lonesome Jan 05 '16 at 12:51

3 Answers3

2

The first thing to do is try to find documentation on the APIs you are using to read the text and XML files. Javadoc, which is what the Java API is documented with, will automatically document all exceptions a method declares. In most cases, catching those exceptions is enough. Also, make sure all method parameters are correct so that a method does not unexpectedly throw NullPointerException, IllegalArgumentException, or something similar.

If you do not know about checked and unchecked exceptions, go read about it now (e.g. Checked vs Unchecked Exception). In short, a method cannot throw a checked exception without declaring it in a throws clause, and the method caller must either catch and handle the exception or declare that it throws the exception. Only exceptions that extend RuntimeException may be thrown by a method without a throws clause, although sometimes programmers declare and/or document these too.

Make sure you understand the different types of exceptions. Anything throwable extends Throwable (See Throwable Javadoc). Error and Exception extend throwable. Error throwables are generally ones you cannot do much about, such as OutOfMemoryError, so it is usually safe to ignore these. Exceptions are the ones you are concerned with. RuntimeException extends Exception, and a runtime exception is unchecked. Anything else that extends Exception is checked.

IO operations generally throw IOException, FileNotFoundException, and SecurityException. IOException is checked, and since FileNotFoundException extends IOException, it is also checked (catching just IOException will handle both). They can be handled separately, but FileNotFoundException will need to be caught before IOException. SecurityException is unchecked, and you are unlikely to see it unless the code is running in a JVM using the security manager to restrict the program (access denied by file permissions is likely to throw IOException).

If you are not sure that your code is catching all the exceptions and handling them properly, then you can always catch Exception and handle that. Alternatively, you can catch Throwable, but then you risk ignoring errors that your program cannot handle and crashing less gracefully. If you do catch Throwable, its a good idea to use it for capturing detailed information and crashing gracefully, such as logging or a GUI application trying to display the error before disappearing from the screen.

Lastly, have a plan for handling the exception. An error I have seen too often is catching an exception, printing and error, and then going on to crash because an IO resource was not initialized. If the method cannot fully recover or crash gracefully, let it throw the exception. Don't forget that you can append information to an exception and use exception chaining so that callees can print a more meaningful error.

For example, suppose your program can read some settings file and it processes it line-by-line. The following method assumes the argument, fileName has been checked already, although you should check arguments explicitly on public methods and throw NullPointerException or IllegalArgumentException accordingly.

/**
 * Read a settings file and configure this object.
 * 
 * @param fileName Name of the file. Must not be <code>null</code>
 *   or empty.
 * 
 * @throws IOException If an IO error occurs while opening or
 *   reading the file.
 * @throws SecurityException If a security manager exists and its
 *   <code>checkRead()</code> method denies read access to the file.
 */
private void loadSettingsFile(String fileName)
        throws IOException, SecurityException {

    String line;  // Line read from file

    // Read file
    try (BufferedReader reader = new BufferedReader(new FileReader(new File(fileName)))) {

        while ((line = reader.readLine()) != null) {
            line = line.trim();

            // Do something with line
        }

    } catch (IOException ex) {
        throw new IOException("IO error reading settings file: " + ex.getMessage(), ex);

    } catch (SecurityException ex) {
        throw new SecurityException("Security error reading settings file: " + ex.getMessage(), ex);

    } catch (Exception ex) {
        throw new IOException(String.format("Unknown error reading settings file: %s: %s", fileName, ex.getMessage()), ex);
    }

    return;
}

In this example, SecurityException and IOException (which also catches FileNotFoundException) are caught and a new exception of the same type is generated with additional information, such as what the program was doing when the exception was thrown. Including the original exception in the new exception (second argument to the constructor) preserves the full stack trace (this is exception chaining). I know that when IOException and SecurityException is thrown in this code, the file name is included; I don't need to add it to the exception again. When other exceptions are thrown, it may not be included, so I explicitly do that when catching Exception.

Note that FileReader() does not declare nor document SecurityException, but it does throw it (verified in OpenJDK 1.7.0_91). This gets back to your question about how you catch all exceptions. Sometimes they are not documented, and you have to guess based on experience. Catching Exception from code you don't know or don't trust is also an option.

In this example, I chose to rethrow Exception as IOException since my callee is already handling those. As a matter of style, I prefer to document all exceptions (even unchecked ones), so this judgment call made sense to me.

Community
  • 1
  • 1
Pete A
  • 34
  • 3
0

There are a number of ways of handling this. Based on your code requirement you need to consider how you want to handle different exceptions. The following code shows how to separate out specific types of exceptions and a catch the remainder at the end.

try {
    // your code here that may throw lots of different exceptions
} catch (AType1Exception ex) {
   // handle the AType1Exception specific exception here
} catch (AType2Exception ex) {
   // handle the AType2Exception specific exception here
} catch (Exception ex) {
   // handle all other exceptions here
}

If you don't have a requirement to handle specific types of exception and just need a general handler for all exceptions you could use

try {
    // your code here that may throw lots of different exceptions
} catch (Exception ex) {
   // handle all exceptions here
}

There are lots of documented references for this issue, more information at this link Catch multiple exceptions at once?

Community
  • 1
  • 1
Mike Murphy
  • 1,006
  • 8
  • 16
0

hahah the only possible solution I can think about is to catch throwable and then check it vs every single type of exception (checked and runtime) and errors which are defined in java.

It will miss only your own Throwable based objects.

Dominik
  • 331
  • 1
  • 4
  • 12