SlideShare a Scribd company logo
1 of 32
Download to read offline
exception handling
best practices

Lemİ Orhan ERGİN
@lemiorhan

lemiorhanergin.com

@lemiorhan
1

Use Checked Exception for Recoverable error &
Unchecked Exception for programming error

Checked exceptions ensures that you provide exception handling code for error
conditions, which is a way from language to enforcing you for writing robust code,
but same time it also add lots of clutter into code and makes it unreadable. Also,
it seems reasonable to catch exception and do something if you have alternatives
or recovery strategies.
2

Avoid overusing Checked Exception
catch block with multiple exceptions
catch  (IOException|SQLException  ex)  {  
        logger.log(ex);  
}

automatic resource management with try-with-resources

java7

java7

static  String  readFirstLineFromFile(String  path)  throws  IOException  {  
        try  (BufferedReader  br  =  new  BufferedReader(new  FileReader(path)))  {  
                return  br.readLine();  
        }  
}  

Checked Exception has there advantage in terms of enforcement, but at same time
it also litters the code and makes it unreadable by obscuring business logic. You can
minimize this by not overusing checked Exception which result in much cleaner code.
You can also use newer Java 7 features like “one catch block for multiple exceptions”
and “automatic resource management”, to remove some duplication.
3

Converting Checked Exception
into RuntimeException
try  {  
      riskyOperation();  
}  catch  (IOException  ioe)  {  
      throw  new  CustomRuntimeException(ioe);  
}

This is one of the technique used to limit use of checked Exception in many of
frameworks like Spring ,where most of checked Exception, which stem from
JDBC is wrapped into DataAccessException, an unchecked Exception. This
Java best practice provides benefits, in terms of restricting specific
exception into specific modules, like SQLException into DAO layer and
throwing meaningful RuntimeException to client layer.
4

Remember Exceptions are costly
in terms of performance

One thing which is worth remembering is that Exceptions are costly, and can
slow down your code. Suppose you have method which is reading from ResultSet
and often throws SQLException than move to next element, will be much slower
than normal code which doesn't throw that Exception. So minimizing catching
unnecessary Exception and moving on, without fixing there root cause. Don’t just
throw and catch exceptions, if you can use boolean variable to indicate result of
operation, which may result in cleaner and performance solution. Avoid
unnecessary Exception handling by fixing root cause.
5

Never swallow the exception in catch block

catch  (NoSuchMethodException  e)  {  
      return  null;  
}

Doing this not only return “null” instead of handling or re-throwing the
exception, it totally swallows the exception, losing the cause of error forever.
And when you don’t know the reason of failure, how you would prevent it in
future? Never do this !!
6

Declare the specific checked exceptions
that your method can throw
public  void  foo()  throws  Exception  {  
}

public  void  foo()  throws  SpecificException1,  SpecificException2  {  
}

Always avoid doing this as in above code sample. It simply defeats the whole
purpose of having checked exception. Declare the specific checked
exceptions that your method can throw. If there are just too many such
checked exceptions, you should probably wrap them in your own exception
and add information to in exception message. You can also consider code
refactoring also if possible.
7

Do not catch the Exception class
rather catch specific sub classes
try  {  
      someMethod();  
}  catch  (Exception  e)  {  
      LOGGER.error("method  has  failed",  e);  
}

The problem with catching Exception is that if the method you are calling later
adds a new checked exception to its method signature, the developer’s intent
is that you should handle the specific new exception. If your code just catches
Exception (or Throwable), you’ll never know about the change and the fact
that your code is now wrong and might break at any point of time in runtime.
8

Never catch Throwable class
try  {  
      someMethod();  
}  catch  (Throwable  t)  {  
      //  handle  throwable  
}

Well, its one step more serious trouble. Because java errors are also
subclasses of the Throwable. Errors are irreversible conditions that can not
be handled by JVM itself. And for some JVM implementations, JVM might
not actually even invoke your catch clause on an Error
9

Always correctly wrap the exceptions in custom
exceptions so that stack trace is not lost

catch  (NoSuchMethodException  e)  {  
      throw  new  MyServiceException("Some  information:  "  +  e.getMessage());  
}
catch  (NoSuchMethodException  e)  {  
      throw  new  MyServiceException("Some  information:  "  ,  e);  
}

Incorrect way of wrapping exceptions destroys the stack trace of the
original exception, and is always wrong.
10

Either log the exception or throw it
but never do the both
catch  (NoSuchMethodException  e)  {  
      LOGGER.error("Some  information",  e);  
      throw  e;  
}

Logging and throwing will result in multiple log messages in log files, for a
single problem in the code, and makes life hell for the engineer who is trying
to dig through the logs.
11

Never throw any exception from finally block
try  {  
    //  Throws  exceptionOne  
    someMethod();    
}  finally  {  
    //  If  finally  also  threw  any  exception,  
    //  the  exceptionOne  will  be  lost  forever  
    cleanUp();          
}

This is fine, as long as cleanUp() can never throw any exception. In the above
example, if someMethod() throws an exception, and in the finally block also,
cleanUp() throws an exception, that second exception will come out of method
and the original first exception (correct reason) will be lost forever. If the code
that you call in a finally block can possibly throw an exception, make sure that
you either handle it, or log it. Never let it come out of the finally block.
12

Always catch only those exceptions
that you can actually handle

catch  (NoSuchMethodException  e)  {  
      throw  e;  
}

Well this is most important concept. Don’t catch any exception just for the sake
of catching it. Catch any exception only if you want to handle it or, you want to
provide additional contextual information in that exception. If you can’t handle it
in catch block, then best advice is just don’t catch it only to re-throw it.
13

Don’t use printStackTrace() statement
or similar methods

catch  (NoSuchMethodException  e)  {  
    System.out.println(e.getStackTrace());  
}

Never leave printStackTrace() after finishing your code. Chances are one of
your fellow colleague will get one of those stack traces eventually, and have
exactly zero knowledge as to what to do with it because it will not have any
contextual information appended to it.
14

Use finally blocks instead of catch blocks
if you are not going to handle exception
try  {  
    someMethod();  
}  finally  {  
    cleanUp();  //do  cleanup  here  
}

This is also a good practice. If inside your method you are accessing
someMethod, and someMethod throws some exception which you do not want
to handle, but still want some cleanup in case exception occur, then do this
cleanup in finally block. Do not use catch block.
15

Remember “Throw early catch late” principle

This is probably the most famous principle about Exception handling. It basically says
that you should throw an exception as soon as you can, and catch it late as much as
possible. You should wait until you have all the information to handle it properly.
!

This principle implicitly says that you will be more likely to throw it in the low-level
methods, where you will be checking if single values are null or not appropriate. And
you will be making the exception climb the stack trace for quite several levels until
you reach a sufficient level of abstraction to be able to handle the problem.
16

Always clean up after handling the exception

If you are using resources like database connections or network
connections, make sure you clean them up. If the API you are invoking
uses only unchecked exceptions, you should still clean up resources
after use, with try – finally blocks. Inside try block access the resource
and inside finally close the resource. Even if any exception occur in
accessing the resource, then also resource will be closed gracefully.
!

You can use new features Java7 to run auto-cleanup via try-withresources statement.
17

Exception names must be
clear and meaningful

Name your checked exceptions stating the cause of the exception. You can
have your own exception hierarchy by extending current Exception class. But for
specific errors, throw an exception like “AccountLockedException” instead of
“AccountException” to be more specific.
18

Throw exceptions for error conditions
while implementing a method

public  void  someMethod()  {  
    //  on  error  1  
    return  -­‐1;  
    //  on  error  2  
    return  -­‐2;  
}

If you return -1, -2, -3 etc. values instead of FileNotFoundException, that method
can not be understand. Use exceptions on errors.
19

Throw only relevant exception from a method

Relevancy is important to keep application clean. A method which tries to read a file;
if throws NullPointerException, then it will not give any relevant information to user.
Instead it will be better if such exception is wrapped inside custom exception e.g.
NoSuchFileFoundException then it will be more useful for users of that method.
20

Never use exceptions for flow control

Never do that. It makes code hard to read, hard to understand and makes it ugly.
21

Never use exceptions for flow control
in your program
try  {  
    //  do  some  logic    
    throw  new  OperationException();  
}  catch  (OperationException  e)  {  
    //  log  the  exception  message  
    //  or  throw  a  new  exception  
}

It is useless to catch the exception you throw in the try block. Do not manage
business logic with exceptions. Use conditional statements instead.
22

One try block must exist for
one basic operation

Granularity is very important. One try block must exist for one basic operation. So
don't put hundreds of lines in a try-catch statement.
23

Do not handle exceptions inside loops
for  (Message  message:messageList)  {  
    try  {  
        //  do  something  that  can  throw  ex.  
    }  catch  (SomeException  e)  {  
        //  handle  exception    
    }  
}
try  {    
    for  (Message  message:messageList)  {  
        //  do  something  that  can  throw  ex.  
    }  
}  catch  (SomeException  e)  {  
    //  handle  exception    
}

Exception handling inside a loop is not recommended for most cases. Surround
the loop with exception block instead.
24

Always include all information
about an exception in single log message

try  {  
  someMethod();  
}  catch  (OperationException  e)  {  
    LOGGER.debug(“some  message”);  
    //  handle  exception  
    LOGGER.debug(“some  another  message”);  
}

Using a multi-line log message with multiple calls to LOGGER.debug() may look
fine in your test case, but when it shows up in the log file of an app server with
400 threads running in parallel, all dumping information to the same log file,
your two log messages may end up spaced out 1000 lines apart in the log file,
even though they occur on subsequent lines in your code.
25

Pass all relevant information to exceptions
to make them informative as much as possible

catch  (SomeException  e)  {  
      logger.log(“error  occurred”,  e);  
}

This is also very important to make exception messages and stack traces useful and
informative. What is the use of a log, if you are not able to determine anything out of
it. These type of logs just exist in your code for decoration purpose.
26

Always terminate the thread
which it is interrupted
while  (true)  {  
    try  {  
        Thread.sleep(100000);  
    }  catch  (InterruptedException  e)  {}  
    doSomethingCool();  
}
while  (true)  {  
    try  {  
        Thread.sleep(100000);  
    }  catch  (InterruptedException  e)  {  
        break;  
    }  
}  
doSomethingCool();

Some common use cases for a thread getting interrupted are the active
transaction timing out, or a thread pool getting shut down. Instead of
ignoring the InterruptedException, your code should do its best to finish up
what it’s doing, and finish the current thread of execution.
27

Use template methods for repeated try-catch

class  DBUtil{  
        public  static  void  closeConnection(Connection  conn){  
                try{  
                        conn.close();  
                }  catch(SQLException  ex){  
                        throw  new  RuntimeException("Cannot  close  connection",  ex);  
                }  
        }  
}
public  void  dataAccessCode()  {  
        Connection  conn  =  null;  
        try{  
                conn  =  getConnection();  
        ....  
        }  finally{  
                DBUtil.closeConnection(conn);  
        }  
}

There is no use of having a similar
catch block in 100 places in your
code. It increases code duplicity
which does not help anything. Use
template methods for such cases.
28

Document all exceptions
in your application in javadoc

Make it a practice to javadoc all exceptions which a piece of code may throw at
runtime. Also try to include possible course of action, user should follow in case
these exception occur.
29

catch all exceptions before
they reach up to the UI

You have to catch all exceptions before they reach up to the UI and
make your user sad. This means on the "highest level" you want to
catch anything that happened further down. Then you can let the user
know there was a problem and at the same time take measures to
inform the developers, like sending out alarm mails or whatever
references
Java exception handling best practices

by Lokesh Gupta

http://howtodoinjava.com/2013/04/04/java-exception-handling-best-practices/

15 Best Practices for Exception Handling

by Cagdas Basaraner

http://codebuild.blogspot.co.uk/2012/01/15-best-practices-about-exception.html

10 Exception handling Best Practices in Java Programming by Javin Paul

http://javarevisited.blogspot.co.uk/2013/03/0-exception-handling-best-practices-in-Java-Programming.html
@lemiorhan
@lemiorhan
@lemiorhan
agilistanbul.com
lemiorhanergin.com

Lemİ orhan ergİn

lemiorhan@agilistanbul.com
Founder & Author @ agilistanbul.com

More Related Content

What's hot (20)

Presentation1
Presentation1Presentation1
Presentation1
 
Clean coding-practices
Clean coding-practicesClean coding-practices
Clean coding-practices
 
Clean code and Code Smells
Clean code and Code SmellsClean code and Code Smells
Clean code and Code Smells
 
Presentation on-exception-handling
Presentation on-exception-handlingPresentation on-exception-handling
Presentation on-exception-handling
 
Code Review Best Practices
Code Review Best PracticesCode Review Best Practices
Code Review Best Practices
 
Clean Code summary
Clean Code summaryClean Code summary
Clean Code summary
 
Exception handling in java
Exception handling in javaException handling in java
Exception handling in java
 
Java 8 features
Java 8 featuresJava 8 features
Java 8 features
 
Exception handling
Exception handlingException handling
Exception handling
 
Clean Code I - Best Practices
Clean Code I - Best PracticesClean Code I - Best Practices
Clean Code I - Best Practices
 
Clean code
Clean codeClean code
Clean code
 
Clean Pragmatic Architecture - Avoiding a Monolith
Clean Pragmatic Architecture - Avoiding a MonolithClean Pragmatic Architecture - Avoiding a Monolith
Clean Pragmatic Architecture - Avoiding a Monolith
 
clean code book summary - uncle bob - English version
clean code book summary - uncle bob - English versionclean code book summary - uncle bob - English version
clean code book summary - uncle bob - English version
 
Exception Handling in C#
Exception Handling in C#Exception Handling in C#
Exception Handling in C#
 
Advanced Reflection in Java
Advanced Reflection in JavaAdvanced Reflection in Java
Advanced Reflection in Java
 
Core java Essentials
Core java EssentialsCore java Essentials
Core java Essentials
 
Real Life Clean Architecture
Real Life Clean ArchitectureReal Life Clean Architecture
Real Life Clean Architecture
 
Clean pragmatic architecture @ devflix
Clean pragmatic architecture @ devflixClean pragmatic architecture @ devflix
Clean pragmatic architecture @ devflix
 
SOLID Design Principles
SOLID Design PrinciplesSOLID Design Principles
SOLID Design Principles
 
Design principle vs design patterns
Design principle vs design patternsDesign principle vs design patterns
Design principle vs design patterns
 

Similar to Best Practices in Exception Handling

Exceptions overview
Exceptions overviewExceptions overview
Exceptions overviewBharath K
 
Exception handling
Exception handlingException handling
Exception handlingzindadili
 
JP ASSIGNMENT SERIES PPT.ppt
JP ASSIGNMENT SERIES PPT.pptJP ASSIGNMENT SERIES PPT.ppt
JP ASSIGNMENT SERIES PPT.pptJAYAPRIYAR7
 
Java SE 11 Exception Handling
Java SE 11 Exception HandlingJava SE 11 Exception Handling
Java SE 11 Exception HandlingAshwin Shiv
 
Exception handling in java
Exception handling in javaException handling in java
Exception handling in javaKavitha713564
 
Exception handling in java
Exception handling in javaException handling in java
Exception handling in javaAmbigaMurugesan
 
Exceptions in java
Exceptions in javaExceptions in java
Exceptions in javaManav Prasad
 
Exception handling in java
Exception handling in javaException handling in java
Exception handling in javaARAFAT ISLAM
 
UNIT-3.pptx Exception Handling and Multithreading
UNIT-3.pptx Exception Handling and MultithreadingUNIT-3.pptx Exception Handling and Multithreading
UNIT-3.pptx Exception Handling and MultithreadingSakkaravarthiS1
 
Java Exception.ppt
Java Exception.pptJava Exception.ppt
Java Exception.pptRanjithaM32
 
Md07 exceptions&assertion
Md07 exceptions&assertionMd07 exceptions&assertion
Md07 exceptions&assertionRakesh Madugula
 

Similar to Best Practices in Exception Handling (20)

Exception handling basic
Exception handling basicException handling basic
Exception handling basic
 
Exceptions overview
Exceptions overviewExceptions overview
Exceptions overview
 
UNIT 2.pptx
UNIT 2.pptxUNIT 2.pptx
UNIT 2.pptx
 
Exception handling
Exception handlingException handling
Exception handling
 
JP ASSIGNMENT SERIES PPT.ppt
JP ASSIGNMENT SERIES PPT.pptJP ASSIGNMENT SERIES PPT.ppt
JP ASSIGNMENT SERIES PPT.ppt
 
Java SE 11 Exception Handling
Java SE 11 Exception HandlingJava SE 11 Exception Handling
Java SE 11 Exception Handling
 
Exception handling in java
Exception handling in javaException handling in java
Exception handling in java
 
Chapter 5
Chapter 5Chapter 5
Chapter 5
 
Exceptionhandling
ExceptionhandlingExceptionhandling
Exceptionhandling
 
Unit 5 Java
Unit 5 JavaUnit 5 Java
Unit 5 Java
 
Exception handling in java
Exception handling in javaException handling in java
Exception handling in java
 
Exceptions in java
Exceptions in javaExceptions in java
Exceptions in java
 
Java exception
Java exception Java exception
Java exception
 
Exception handling in java
Exception handling in javaException handling in java
Exception handling in java
 
Java exception-handling
Java exception-handlingJava exception-handling
Java exception-handling
 
Java Exceptions Handling
Java Exceptions Handling Java Exceptions Handling
Java Exceptions Handling
 
Java Exceptions
Java ExceptionsJava Exceptions
Java Exceptions
 
UNIT-3.pptx Exception Handling and Multithreading
UNIT-3.pptx Exception Handling and MultithreadingUNIT-3.pptx Exception Handling and Multithreading
UNIT-3.pptx Exception Handling and Multithreading
 
Java Exception.ppt
Java Exception.pptJava Exception.ppt
Java Exception.ppt
 
Md07 exceptions&assertion
Md07 exceptions&assertionMd07 exceptions&assertion
Md07 exceptions&assertion
 

More from Lemi Orhan Ergin

Clean Software Design: The Practices to Make The Design Simple
Clean Software Design: The Practices to Make The Design SimpleClean Software Design: The Practices to Make The Design Simple
Clean Software Design: The Practices to Make The Design SimpleLemi Orhan Ergin
 
Unwritten Manual for Pair Programming
Unwritten Manual for Pair ProgrammingUnwritten Manual for Pair Programming
Unwritten Manual for Pair ProgrammingLemi Orhan Ergin
 
10 Faulty Behaviors of Code Review - Developer Summit Istanbul 2018
10 Faulty Behaviors of Code Review - Developer Summit Istanbul 201810 Faulty Behaviors of Code Review - Developer Summit Istanbul 2018
10 Faulty Behaviors of Code Review - Developer Summit Istanbul 2018Lemi Orhan Ergin
 
Yeni Nesil Yazılım Kültürü: Daha İyi Profesyoneller, Daha Kaliteli Yazılım, D...
Yeni Nesil Yazılım Kültürü: Daha İyi Profesyoneller, Daha Kaliteli Yazılım, D...Yeni Nesil Yazılım Kültürü: Daha İyi Profesyoneller, Daha Kaliteli Yazılım, D...
Yeni Nesil Yazılım Kültürü: Daha İyi Profesyoneller, Daha Kaliteli Yazılım, D...Lemi Orhan Ergin
 
Irresponsible Disclosure: Short Handbook of an Ethical Developer
Irresponsible Disclosure: Short Handbook of an Ethical DeveloperIrresponsible Disclosure: Short Handbook of an Ethical Developer
Irresponsible Disclosure: Short Handbook of an Ethical DeveloperLemi Orhan Ergin
 
Scrum Events and Artifacts in Action
Scrum Events and Artifacts in ActionScrum Events and Artifacts in Action
Scrum Events and Artifacts in ActionLemi Orhan Ergin
 
DevOps & Technical Agility: From Theory to Practice
DevOps & Technical Agility: From Theory to PracticeDevOps & Technical Agility: From Theory to Practice
DevOps & Technical Agility: From Theory to PracticeLemi Orhan Ergin
 
Fighting with Waste Driven Development - XP Days Ukraine 2017
Fighting with Waste Driven Development - XP Days Ukraine 2017Fighting with Waste Driven Development - XP Days Ukraine 2017
Fighting with Waste Driven Development - XP Days Ukraine 2017Lemi Orhan Ergin
 
Git Anti Patterns - XP Days Ukraine 2017
Git Anti Patterns - XP Days Ukraine 2017Git Anti Patterns - XP Days Ukraine 2017
Git Anti Patterns - XP Days Ukraine 2017Lemi Orhan Ergin
 
Waste Driven Development - Agile Coaching Serbia Meetup
Waste Driven Development - Agile Coaching Serbia MeetupWaste Driven Development - Agile Coaching Serbia Meetup
Waste Driven Development - Agile Coaching Serbia MeetupLemi Orhan Ergin
 
Git Anti-Patterns - Extended Version With 28 Common Anti-Patterns) - SCTurkey...
Git Anti-Patterns - Extended Version With 28 Common Anti-Patterns) - SCTurkey...Git Anti-Patterns - Extended Version With 28 Common Anti-Patterns) - SCTurkey...
Git Anti-Patterns - Extended Version With 28 Common Anti-Patterns) - SCTurkey...Lemi Orhan Ergin
 
Git Anti-Patterns: How To Mess Up With Git and Love it Again - DevoxxPL 2017
Git Anti-Patterns: How To Mess Up With Git and Love it Again - DevoxxPL 2017Git Anti-Patterns: How To Mess Up With Git and Love it Again - DevoxxPL 2017
Git Anti-Patterns: How To Mess Up With Git and Love it Again - DevoxxPL 2017Lemi Orhan Ergin
 
Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...
Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...
Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...Lemi Orhan Ergin
 
Git Anti-Patterns: How To Mess Up With Git and Love it Again
Git Anti-Patterns: How To Mess Up With Git and Love it AgainGit Anti-Patterns: How To Mess Up With Git and Love it Again
Git Anti-Patterns: How To Mess Up With Git and Love it AgainLemi Orhan Ergin
 
Clean Software Design - DevNot Summit Istanbul 2017
Clean Software Design - DevNot Summit Istanbul 2017Clean Software Design - DevNot Summit Istanbul 2017
Clean Software Design - DevNot Summit Istanbul 2017Lemi Orhan Ergin
 
Test Driven Design - GDG DevFest Istanbul 2016
Test Driven Design - GDG DevFest Istanbul 2016Test Driven Design - GDG DevFest Istanbul 2016
Test Driven Design - GDG DevFest Istanbul 2016Lemi Orhan Ergin
 
Let The Elephants Leave The Room - Remove Waste in Software Development - Bos...
Let The Elephants Leave The Room - Remove Waste in Software Development - Bos...Let The Elephants Leave The Room - Remove Waste in Software Development - Bos...
Let The Elephants Leave The Room - Remove Waste in Software Development - Bos...Lemi Orhan Ergin
 
Happy Developer's Guide to the Galaxy: Thinking About Motivation of Developers
Happy Developer's Guide to the Galaxy: Thinking About Motivation of DevelopersHappy Developer's Guide to the Galaxy: Thinking About Motivation of Developers
Happy Developer's Guide to the Galaxy: Thinking About Motivation of DevelopersLemi Orhan Ergin
 
Git - Bildiğiniz Gibi Değil
Git - Bildiğiniz Gibi DeğilGit - Bildiğiniz Gibi Değil
Git - Bildiğiniz Gibi DeğilLemi Orhan Ergin
 
Code Your Agility - Tips for Boosting Technical Agility in Your Organization
Code Your Agility - Tips for Boosting Technical Agility in Your OrganizationCode Your Agility - Tips for Boosting Technical Agility in Your Organization
Code Your Agility - Tips for Boosting Technical Agility in Your OrganizationLemi Orhan Ergin
 

More from Lemi Orhan Ergin (20)

Clean Software Design: The Practices to Make The Design Simple
Clean Software Design: The Practices to Make The Design SimpleClean Software Design: The Practices to Make The Design Simple
Clean Software Design: The Practices to Make The Design Simple
 
Unwritten Manual for Pair Programming
Unwritten Manual for Pair ProgrammingUnwritten Manual for Pair Programming
Unwritten Manual for Pair Programming
 
10 Faulty Behaviors of Code Review - Developer Summit Istanbul 2018
10 Faulty Behaviors of Code Review - Developer Summit Istanbul 201810 Faulty Behaviors of Code Review - Developer Summit Istanbul 2018
10 Faulty Behaviors of Code Review - Developer Summit Istanbul 2018
 
Yeni Nesil Yazılım Kültürü: Daha İyi Profesyoneller, Daha Kaliteli Yazılım, D...
Yeni Nesil Yazılım Kültürü: Daha İyi Profesyoneller, Daha Kaliteli Yazılım, D...Yeni Nesil Yazılım Kültürü: Daha İyi Profesyoneller, Daha Kaliteli Yazılım, D...
Yeni Nesil Yazılım Kültürü: Daha İyi Profesyoneller, Daha Kaliteli Yazılım, D...
 
Irresponsible Disclosure: Short Handbook of an Ethical Developer
Irresponsible Disclosure: Short Handbook of an Ethical DeveloperIrresponsible Disclosure: Short Handbook of an Ethical Developer
Irresponsible Disclosure: Short Handbook of an Ethical Developer
 
Scrum Events and Artifacts in Action
Scrum Events and Artifacts in ActionScrum Events and Artifacts in Action
Scrum Events and Artifacts in Action
 
DevOps & Technical Agility: From Theory to Practice
DevOps & Technical Agility: From Theory to PracticeDevOps & Technical Agility: From Theory to Practice
DevOps & Technical Agility: From Theory to Practice
 
Fighting with Waste Driven Development - XP Days Ukraine 2017
Fighting with Waste Driven Development - XP Days Ukraine 2017Fighting with Waste Driven Development - XP Days Ukraine 2017
Fighting with Waste Driven Development - XP Days Ukraine 2017
 
Git Anti Patterns - XP Days Ukraine 2017
Git Anti Patterns - XP Days Ukraine 2017Git Anti Patterns - XP Days Ukraine 2017
Git Anti Patterns - XP Days Ukraine 2017
 
Waste Driven Development - Agile Coaching Serbia Meetup
Waste Driven Development - Agile Coaching Serbia MeetupWaste Driven Development - Agile Coaching Serbia Meetup
Waste Driven Development - Agile Coaching Serbia Meetup
 
Git Anti-Patterns - Extended Version With 28 Common Anti-Patterns) - SCTurkey...
Git Anti-Patterns - Extended Version With 28 Common Anti-Patterns) - SCTurkey...Git Anti-Patterns - Extended Version With 28 Common Anti-Patterns) - SCTurkey...
Git Anti-Patterns - Extended Version With 28 Common Anti-Patterns) - SCTurkey...
 
Git Anti-Patterns: How To Mess Up With Git and Love it Again - DevoxxPL 2017
Git Anti-Patterns: How To Mess Up With Git and Love it Again - DevoxxPL 2017Git Anti-Patterns: How To Mess Up With Git and Love it Again - DevoxxPL 2017
Git Anti-Patterns: How To Mess Up With Git and Love it Again - DevoxxPL 2017
 
Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...
Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...
Yazılım Geliştirme Kültürünün Kodları: Motivasyon, Teknik Mükemmellik ve İnov...
 
Git Anti-Patterns: How To Mess Up With Git and Love it Again
Git Anti-Patterns: How To Mess Up With Git and Love it AgainGit Anti-Patterns: How To Mess Up With Git and Love it Again
Git Anti-Patterns: How To Mess Up With Git and Love it Again
 
Clean Software Design - DevNot Summit Istanbul 2017
Clean Software Design - DevNot Summit Istanbul 2017Clean Software Design - DevNot Summit Istanbul 2017
Clean Software Design - DevNot Summit Istanbul 2017
 
Test Driven Design - GDG DevFest Istanbul 2016
Test Driven Design - GDG DevFest Istanbul 2016Test Driven Design - GDG DevFest Istanbul 2016
Test Driven Design - GDG DevFest Istanbul 2016
 
Let The Elephants Leave The Room - Remove Waste in Software Development - Bos...
Let The Elephants Leave The Room - Remove Waste in Software Development - Bos...Let The Elephants Leave The Room - Remove Waste in Software Development - Bos...
Let The Elephants Leave The Room - Remove Waste in Software Development - Bos...
 
Happy Developer's Guide to the Galaxy: Thinking About Motivation of Developers
Happy Developer's Guide to the Galaxy: Thinking About Motivation of DevelopersHappy Developer's Guide to the Galaxy: Thinking About Motivation of Developers
Happy Developer's Guide to the Galaxy: Thinking About Motivation of Developers
 
Git - Bildiğiniz Gibi Değil
Git - Bildiğiniz Gibi DeğilGit - Bildiğiniz Gibi Değil
Git - Bildiğiniz Gibi Değil
 
Code Your Agility - Tips for Boosting Technical Agility in Your Organization
Code Your Agility - Tips for Boosting Technical Agility in Your OrganizationCode Your Agility - Tips for Boosting Technical Agility in Your Organization
Code Your Agility - Tips for Boosting Technical Agility in Your Organization
 

Recently uploaded

AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesMd Hossain Ali
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...Aggregage
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Brian Pichman
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6DianaGray10
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Websitedgelyza
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?IES VE
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsSafe Software
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfinfogdgmi
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfDianaGray10
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXTarek Kalaji
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
NIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopNIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopBachir Benyammi
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfJamie (Taka) Wang
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 

Recently uploaded (20)

AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
201610817 - edge part1
201610817 - edge part1201610817 - edge part1
201610817 - edge part1
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Website
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdf
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBX
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
NIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopNIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 Workshop
 
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
activity_diagram_combine_v4_20190827.pdfactivity_diagram_combine_v4_20190827.pdf
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 

Best Practices in Exception Handling

  • 1. exception handling best practices Lemİ Orhan ERGİN @lemiorhan lemiorhanergin.com @lemiorhan
  • 2. 1 Use Checked Exception for Recoverable error & Unchecked Exception for programming error Checked exceptions ensures that you provide exception handling code for error conditions, which is a way from language to enforcing you for writing robust code, but same time it also add lots of clutter into code and makes it unreadable. Also, it seems reasonable to catch exception and do something if you have alternatives or recovery strategies.
  • 3. 2 Avoid overusing Checked Exception catch block with multiple exceptions catch  (IOException|SQLException  ex)  {          logger.log(ex);   } automatic resource management with try-with-resources java7 java7 static  String  readFirstLineFromFile(String  path)  throws  IOException  {          try  (BufferedReader  br  =  new  BufferedReader(new  FileReader(path)))  {                  return  br.readLine();          }   }   Checked Exception has there advantage in terms of enforcement, but at same time it also litters the code and makes it unreadable by obscuring business logic. You can minimize this by not overusing checked Exception which result in much cleaner code. You can also use newer Java 7 features like “one catch block for multiple exceptions” and “automatic resource management”, to remove some duplication.
  • 4. 3 Converting Checked Exception into RuntimeException try  {        riskyOperation();   }  catch  (IOException  ioe)  {        throw  new  CustomRuntimeException(ioe);   } This is one of the technique used to limit use of checked Exception in many of frameworks like Spring ,where most of checked Exception, which stem from JDBC is wrapped into DataAccessException, an unchecked Exception. This Java best practice provides benefits, in terms of restricting specific exception into specific modules, like SQLException into DAO layer and throwing meaningful RuntimeException to client layer.
  • 5. 4 Remember Exceptions are costly in terms of performance One thing which is worth remembering is that Exceptions are costly, and can slow down your code. Suppose you have method which is reading from ResultSet and often throws SQLException than move to next element, will be much slower than normal code which doesn't throw that Exception. So minimizing catching unnecessary Exception and moving on, without fixing there root cause. Don’t just throw and catch exceptions, if you can use boolean variable to indicate result of operation, which may result in cleaner and performance solution. Avoid unnecessary Exception handling by fixing root cause.
  • 6. 5 Never swallow the exception in catch block catch  (NoSuchMethodException  e)  {        return  null;   } Doing this not only return “null” instead of handling or re-throwing the exception, it totally swallows the exception, losing the cause of error forever. And when you don’t know the reason of failure, how you would prevent it in future? Never do this !!
  • 7. 6 Declare the specific checked exceptions that your method can throw public  void  foo()  throws  Exception  {   } public  void  foo()  throws  SpecificException1,  SpecificException2  {   } Always avoid doing this as in above code sample. It simply defeats the whole purpose of having checked exception. Declare the specific checked exceptions that your method can throw. If there are just too many such checked exceptions, you should probably wrap them in your own exception and add information to in exception message. You can also consider code refactoring also if possible.
  • 8. 7 Do not catch the Exception class rather catch specific sub classes try  {        someMethod();   }  catch  (Exception  e)  {        LOGGER.error("method  has  failed",  e);   } The problem with catching Exception is that if the method you are calling later adds a new checked exception to its method signature, the developer’s intent is that you should handle the specific new exception. If your code just catches Exception (or Throwable), you’ll never know about the change and the fact that your code is now wrong and might break at any point of time in runtime.
  • 9. 8 Never catch Throwable class try  {        someMethod();   }  catch  (Throwable  t)  {        //  handle  throwable   } Well, its one step more serious trouble. Because java errors are also subclasses of the Throwable. Errors are irreversible conditions that can not be handled by JVM itself. And for some JVM implementations, JVM might not actually even invoke your catch clause on an Error
  • 10. 9 Always correctly wrap the exceptions in custom exceptions so that stack trace is not lost catch  (NoSuchMethodException  e)  {        throw  new  MyServiceException("Some  information:  "  +  e.getMessage());   } catch  (NoSuchMethodException  e)  {        throw  new  MyServiceException("Some  information:  "  ,  e);   } Incorrect way of wrapping exceptions destroys the stack trace of the original exception, and is always wrong.
  • 11. 10 Either log the exception or throw it but never do the both catch  (NoSuchMethodException  e)  {        LOGGER.error("Some  information",  e);        throw  e;   } Logging and throwing will result in multiple log messages in log files, for a single problem in the code, and makes life hell for the engineer who is trying to dig through the logs.
  • 12. 11 Never throw any exception from finally block try  {      //  Throws  exceptionOne      someMethod();     }  finally  {      //  If  finally  also  threw  any  exception,      //  the  exceptionOne  will  be  lost  forever      cleanUp();           } This is fine, as long as cleanUp() can never throw any exception. In the above example, if someMethod() throws an exception, and in the finally block also, cleanUp() throws an exception, that second exception will come out of method and the original first exception (correct reason) will be lost forever. If the code that you call in a finally block can possibly throw an exception, make sure that you either handle it, or log it. Never let it come out of the finally block.
  • 13. 12 Always catch only those exceptions that you can actually handle catch  (NoSuchMethodException  e)  {        throw  e;   } Well this is most important concept. Don’t catch any exception just for the sake of catching it. Catch any exception only if you want to handle it or, you want to provide additional contextual information in that exception. If you can’t handle it in catch block, then best advice is just don’t catch it only to re-throw it.
  • 14. 13 Don’t use printStackTrace() statement or similar methods catch  (NoSuchMethodException  e)  {      System.out.println(e.getStackTrace());   } Never leave printStackTrace() after finishing your code. Chances are one of your fellow colleague will get one of those stack traces eventually, and have exactly zero knowledge as to what to do with it because it will not have any contextual information appended to it.
  • 15. 14 Use finally blocks instead of catch blocks if you are not going to handle exception try  {      someMethod();   }  finally  {      cleanUp();  //do  cleanup  here   } This is also a good practice. If inside your method you are accessing someMethod, and someMethod throws some exception which you do not want to handle, but still want some cleanup in case exception occur, then do this cleanup in finally block. Do not use catch block.
  • 16. 15 Remember “Throw early catch late” principle This is probably the most famous principle about Exception handling. It basically says that you should throw an exception as soon as you can, and catch it late as much as possible. You should wait until you have all the information to handle it properly. ! This principle implicitly says that you will be more likely to throw it in the low-level methods, where you will be checking if single values are null or not appropriate. And you will be making the exception climb the stack trace for quite several levels until you reach a sufficient level of abstraction to be able to handle the problem.
  • 17. 16 Always clean up after handling the exception If you are using resources like database connections or network connections, make sure you clean them up. If the API you are invoking uses only unchecked exceptions, you should still clean up resources after use, with try – finally blocks. Inside try block access the resource and inside finally close the resource. Even if any exception occur in accessing the resource, then also resource will be closed gracefully. ! You can use new features Java7 to run auto-cleanup via try-withresources statement.
  • 18. 17 Exception names must be clear and meaningful Name your checked exceptions stating the cause of the exception. You can have your own exception hierarchy by extending current Exception class. But for specific errors, throw an exception like “AccountLockedException” instead of “AccountException” to be more specific.
  • 19. 18 Throw exceptions for error conditions while implementing a method public  void  someMethod()  {      //  on  error  1      return  -­‐1;      //  on  error  2      return  -­‐2;   } If you return -1, -2, -3 etc. values instead of FileNotFoundException, that method can not be understand. Use exceptions on errors.
  • 20. 19 Throw only relevant exception from a method Relevancy is important to keep application clean. A method which tries to read a file; if throws NullPointerException, then it will not give any relevant information to user. Instead it will be better if such exception is wrapped inside custom exception e.g. NoSuchFileFoundException then it will be more useful for users of that method.
  • 21. 20 Never use exceptions for flow control Never do that. It makes code hard to read, hard to understand and makes it ugly.
  • 22. 21 Never use exceptions for flow control in your program try  {      //  do  some  logic        throw  new  OperationException();   }  catch  (OperationException  e)  {      //  log  the  exception  message      //  or  throw  a  new  exception   } It is useless to catch the exception you throw in the try block. Do not manage business logic with exceptions. Use conditional statements instead.
  • 23. 22 One try block must exist for one basic operation Granularity is very important. One try block must exist for one basic operation. So don't put hundreds of lines in a try-catch statement.
  • 24. 23 Do not handle exceptions inside loops for  (Message  message:messageList)  {      try  {          //  do  something  that  can  throw  ex.      }  catch  (SomeException  e)  {          //  handle  exception        }   } try  {        for  (Message  message:messageList)  {          //  do  something  that  can  throw  ex.      }   }  catch  (SomeException  e)  {      //  handle  exception     } Exception handling inside a loop is not recommended for most cases. Surround the loop with exception block instead.
  • 25. 24 Always include all information about an exception in single log message try  {    someMethod();   }  catch  (OperationException  e)  {      LOGGER.debug(“some  message”);      //  handle  exception      LOGGER.debug(“some  another  message”);   } Using a multi-line log message with multiple calls to LOGGER.debug() may look fine in your test case, but when it shows up in the log file of an app server with 400 threads running in parallel, all dumping information to the same log file, your two log messages may end up spaced out 1000 lines apart in the log file, even though they occur on subsequent lines in your code.
  • 26. 25 Pass all relevant information to exceptions to make them informative as much as possible catch  (SomeException  e)  {        logger.log(“error  occurred”,  e);   } This is also very important to make exception messages and stack traces useful and informative. What is the use of a log, if you are not able to determine anything out of it. These type of logs just exist in your code for decoration purpose.
  • 27. 26 Always terminate the thread which it is interrupted while  (true)  {      try  {          Thread.sleep(100000);      }  catch  (InterruptedException  e)  {}      doSomethingCool();   } while  (true)  {      try  {          Thread.sleep(100000);      }  catch  (InterruptedException  e)  {          break;      }   }   doSomethingCool(); Some common use cases for a thread getting interrupted are the active transaction timing out, or a thread pool getting shut down. Instead of ignoring the InterruptedException, your code should do its best to finish up what it’s doing, and finish the current thread of execution.
  • 28. 27 Use template methods for repeated try-catch class  DBUtil{          public  static  void  closeConnection(Connection  conn){                  try{                          conn.close();                  }  catch(SQLException  ex){                          throw  new  RuntimeException("Cannot  close  connection",  ex);                  }          }   } public  void  dataAccessCode()  {          Connection  conn  =  null;          try{                  conn  =  getConnection();        ....          }  finally{                  DBUtil.closeConnection(conn);          }   } There is no use of having a similar catch block in 100 places in your code. It increases code duplicity which does not help anything. Use template methods for such cases.
  • 29. 28 Document all exceptions in your application in javadoc Make it a practice to javadoc all exceptions which a piece of code may throw at runtime. Also try to include possible course of action, user should follow in case these exception occur.
  • 30. 29 catch all exceptions before they reach up to the UI You have to catch all exceptions before they reach up to the UI and make your user sad. This means on the "highest level" you want to catch anything that happened further down. Then you can let the user know there was a problem and at the same time take measures to inform the developers, like sending out alarm mails or whatever
  • 31. references Java exception handling best practices by Lokesh Gupta http://howtodoinjava.com/2013/04/04/java-exception-handling-best-practices/ 15 Best Practices for Exception Handling by Cagdas Basaraner http://codebuild.blogspot.co.uk/2012/01/15-best-practices-about-exception.html 10 Exception handling Best Practices in Java Programming by Javin Paul http://javarevisited.blogspot.co.uk/2013/03/0-exception-handling-best-practices-in-Java-Programming.html