java - What is the Best practice for try catch blocks to create clean code? -

possible duplicate:
best practices exception management in java or c#

i've read a question earlier today on stackoverflow , made me think best practice handling exceptions.

so, question what best practice handle exceptions produce clean , high quality code.

here code, think it's quiet straight forward please let me know if i'm wrong or not clear! i've tried keep in mind testability , same abstraction level in methods.

every constructive comment welcomed. :)

import java.awt.point; import java.io.closeable; import java.io.fileinputstream; import java.io.filenotfoundexception; import java.io.ioexception; import java.io.objectinputstream; import java.util.list;  import org.slf4j.logger; import org.slf4j.loggerfactory;  import com.google.common.base.preconditions;  /**  * <p>this dummy code.</p>  * aim present best practice on exception separation , handling.  */ public class exceptionhandlingdemo {     // system.out not practice. using logger testing (can checked if expected error messages produced).     private logger logger = loggerfactory.getlogger(exceptionhandlingdemo.class);      // instance of cannot work list<point>     private interface pointlist extends list<point> {}      /**      * method loads list of points file.      * @param path - path , name of file loaded.      * precondition: path cannot {@code null}. in such case {@link nullpointerexception} thrown.       * postcondition: if file don't exist, ioexception occurs or file doesn't contain list returned object {@code null}.      * */     /* (google throws nullpointerexceptio) since not forbidden developers throw it. know arguable out of topic now. */     public list<point> loadpointlist(final string path) {         preconditions.checknotnull(path, "the path of file cannot null");          list<point> pointlisttoreturn = null;         objectinputstream in = null;          try {             in = openobjectinputstream(path);             pointlisttoreturn = readpointlist(in);         } catch (final throwable throwable) {             handleexception(throwable);         } {             close(in);         }          return pointlisttoreturn;     }      /*======== private helper methods ========*/      private objectinputstream openobjectinputstream(final string filename) throws filenotfoundexception, ioexception {         return new objectinputstream(new fileinputstream(filename));     }      private list<point> readpointlist(final objectinputstream objectinputstream) throws ioexception, classnotfoundexception {         final object object = objectinputstream.readobject();          list<point> ret = null;          if (object instanceof pointlist) {             ret = (pointlist) object;         }         return ret;     }      private void handleexception(final throwable throwable) {         // don't know best practice here ...         logger.error(throwable.tostring());     }      private void close(final closeable closeable) {          if (closeable != null) {             try {                 closeable.close();             } catch (ioexception e) {                 logger.error("failed closing: %s", closeable);             }         }     }      /*======== getters , setters now. ========*/      // ...      /**      * @param args      */     public static void main(string[] args) {         exceptionhandlingdemo test = new exceptionhandlingdemo();         test.loadpointlist("test-filename.ext");     } } 

edited:

what want avoid writing lot of catch cases after each other...

a few suggestions @ first glance:

1. you shouldn't catch throwable , instead catch specific of exception possible. trouble catching throwable include error classes outofmemoryerror , like. want let pass through (they're unchecked reason).
2. when log exceptions always pass exception , not tostring(). it's hard diagnose problems without stack trace.
3. you don't want general exception handling method.

so @ places catch exceptions want this:

} catch (ioexception e) {     logger.error("some relevant message", e);     // handle exception case } 

the message should include contextual information if possible. might tracking down problem when hunting through logs.