際際滷

際際滷Share a Scribd company logo

Errorhandlingppt

Download as PPTX, PDF
Pavel Shabalin
Pavel Shabalin

This document discusses reducing duplicate exception handling code in an InvestCloud project. It finds that there are 86 exception classes extending Exception, resulting in around 2400 lines of identical exception code. It also finds around 1700 lines of code catching two specific exception types. The document proposes defining a small set of common exception types in a shared module and using a CXF ExceptionMapper to translate exceptions to responses to dramatically reduce exception code and clean up endpoint classes. This approach would have several pros including a reduced and well-defined exception set, single point of error handling, and increased productivity.

1 of 8
Download to read offline
Typical Exception in InvestCloud project
Lets do the numbers 1. Typical Exception class lines count 28 2. 86classes extends Exception in the project codebase 3. 28 * 86 = ~2400lines of identical code What is the reason to have and maintain this code?
Typical Exception handling AccountResource FirmResource
Exception handling (part 2) (AccountResource again)
Lets do the numbers 2 $ grep -c -R --include=*.java ".*} catch .*ServiceException" * > out && awk -F : '{total += $2} END { print "Total:", total }' out 1. *ServiceException catch statements total count 320 2. *PersistenceException catch statements count 248 3. Typical handler code rows count 3 4. Total handlers code rows count 320+248 * 3 = ~1700 Total: 1700 + 2400 = 4100 lines of code
Proposed approach Define small set of all exceptional situations which may occur in the application: 1. ResourceNotFoundException 2. AccessDeniedException 3. EntityAlreadyExistsException . N. InvestCloudException the generic service exception for all unknown type of errors
Proposed approach 2 1. Put all exception classed into shared module investcloud-services 2. Implement cxf ExceptionMapper to translate exceptions into appropriate response (data and HTTP response code)
Your thoughts please PROS: 1. Dramatically reduced exception and exception codebase 2. Well defined set of exceptional situations 3. Single point of error handling (better testability) 4. Cleaning up endpoint classes from error prone code 5. All of that makes us more productive

More Related Content

Errorhandlingppt

  • 1. Typical Exception in InvestCloud project
  • 2. Lets do the numbers 1. Typical Exception class lines count 28 2. 86classes extends Exception in the project codebase 3. 28 * 86 = ~2400lines of identical code What is the reason to have and maintain this code?
  • 4. Exception handling (part 2) (AccountResource again)
  • 5. Lets do the numbers 2 $ grep -c -R --include=*.java ".*} catch .*ServiceException" * > out && awk -F : '{total += $2} END { print "Total:", total }' out 1. *ServiceException catch statements total count 320 2. *PersistenceException catch statements count 248 3. Typical handler code rows count 3 4. Total handlers code rows count 320+248 * 3 = ~1700 Total: 1700 + 2400 = 4100 lines of code
  • 6. Proposed approach Define small set of all exceptional situations which may occur in the application: 1. ResourceNotFoundException 2. AccessDeniedException 3. EntityAlreadyExistsException . N. InvestCloudException the generic service exception for all unknown type of errors
  • 7. Proposed approach 2 1. Put all exception classed into shared module investcloud-services 2. Implement cxf ExceptionMapper to translate exceptions into appropriate response (data and HTTP response code)
  • 8. Your thoughts please PROS: 1. Dramatically reduced exception and exception codebase 2. Well defined set of exceptional situations 3. Single point of error handling (better testability) 4. Cleaning up endpoint classes from error prone code 5. All of that makes us more productive