Exceptions

[gangsta1903]

As far as I know, exceptions that are not subclasses of runtime exception or error should be caught (handled).

When a file exception occurs, it should be caught because its a subclass of exception class, but how can it be recovered? If file is not found,it sounds silly to recover it when the program has to read file to run,I think the program should be terminated.

} catch (IOException e) {
            e.printStackTrace();
            System.exit(0);
} finally {
        if(in != null)
           in.close();
}

I preferred to exit in catch block,what should be done in such a situation?

[peter_budo]

Existing with stack of errors meaningful only to you as the programmer, alien to the user is bad design.
You should re trite gratefully with appropriate error message to the user and do not shut down program, just return to the point where the file name been submitted for new entry

[gangsta1903]

I understand what you want to tell. Waiting a valid input file may be a good choice.
But, if I don't want to give that right to the user, I mean user has to enter a valid filename at his first choice,else the program has to be terminated. In my program, the absence of that file corrupts program running,that's too, I regard it as RuntimeException and treat it like that. I am asking what else may be done,because Java books suggest not to use exit statement in exceptions.

[jasimp]

I understand what you want to tell. Waiting a valid input file may be a good choice.
But, if I don't want to give that right to the user, I mean user has to enter a valid filename at his first choice,else the program has to be terminated. In my program, the absence of that file corrupts program running,that's too, I regard it as RuntimeException and treat it like that. I am asking what else may be done,because Java books suggest not to use exit statement in exceptions.

Peter already said what to do. He said do not exit the program, provide a helpful message to the user and then go back "to the point the file name been submitted for new entry".

[dickersonka]

you can do something like return a boolean

public boolean loadFile(){
boolean readFile = Boolean.FALSE;

try {
  //load file
  readFile = Boolean.TRUE;
} catch (IOException e) {
            e.printStackTrace();
} finally {
        if(in != null)
           in.close();
}

return readFile;
}

//your calling code
if(loadFile()){
 //continue
} else {
  //we need to tell the user that the file couldn't be loaded
}

[~s.o.s~]

As far as I know, exceptions that are not subclasses of runtime exception or error should be caught (handled).

When a file exception occurs, it should be caught because its a subclass of exception class, but how can it be recovered? If file is not found,it sounds silly to recover it when the program has to read file to run,I think the program should be terminated.

} catch (IOException e) {
            e.printStackTrace();
            System.exit(0);
} finally {
        if(in != null)
           in.close();
}

I preferred to exit in catch block,what should be done in such a situation?

Making IOException and SQLException as checked exceptions is regarded as one of the blunders of the Java standard library design. Many might argue that having checked exceptions in itself is a big PITA but that's a story for some other day.

Anyways, just make sure you don't propagate error codes anywhere in your application design; it's one of the worst design decisions to make esp when using a language like Java which has exceptions built in.

You have two options here:
- Either let the method throw the same IOException which occurs and let the invoking method handle the case. This seems to be a bad choice since the calling method now has to handle an exception it shouldn't have been bothered with in the first place.
- Create your own RuntimeException class which fits ecosystem of your application and wraps around the IOException thrown. This exception should be thrown when an IOException occurs in the called method and is handled as per required by your application.

[gangsta1903]

- Create your own RuntimeException class which fits ecosystem of your application and wraps around the IOException thrown. This exception should be thrown when an IOException occurs in the called method and is handled as per required by your application.

What exactly does this mean?

[~s.o.s~]

This means that instead of either catching IOException and doing nothing or making the method throw IOException , introduce a custom exception hierarchy for your application. This hierarchy might contain something from two to twenty custom exceptions depending on the breadth of your application.

For e.g. in the above case, you might just create a custom Exception class which extends RuntimeException and use it to wrap the actual IOException which occurs in your code.

public void someMethod(String fileName) {
  try {
  } catch(IOException ioe) {
    throw new SystemException("File not found: " + fileName, ioe);
  }
}

Since the exception is unchecked type, it gives you the flexibility to completely ignore the possibility of an exception occurring when reading a given file or handle it in case you feel like it and process it accordingly. Just make sure you specify the cause when creating a new Exception instance so that it can be used for logging or other debugging purposes.

[gangsta1903]

ok,now I see it,
thanks...