Your SlideShare is downloading. ×
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Exceptions irst
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Exceptions irst

727

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
727
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Exceptions First "Both optimists and pessimists contribute to society. The optimist invents the airplane, the pessimist invents the parachute." — George Bernard Shaw
  • 2. Exceptional Cases
    • This CANNOT be covered in requirements, its developers' sole responsibility
    • For a single happy scenario, You may need 10 erroneous scenarios, which makes your effort 11 times bigger than what you think.
    • Always fear about the failure during the development. What if
      • the input becomes null?
      • this transaction failed? Should we roll back?
      • this checked exception happens? Should I handle it? Or propagate back?
      • There is a runtime exception? Can the system handle? Who builds the system anyway?
  • 3. Tom, JK & Harry’s codes
    • try {
    • //do something;
    • } catch (IOException e) {
    • e.printStackTrace();
    • }
  • 4. Tom, JK & Harry’s codes
    • try {
    • //do something;
    • } catch (IOException e) {
    • //This is it
    • }
  • 5. Tom, JK & Harry’s codes
    • try {
    • return something;
    • } catch (IOException e) {
    • return “”;
    • }
  • 6. Tom, JK & Harry’s codes
    • if(something wrong){
      • throw new Exception (“Error”);
    • }
  • 7. Unchecked Vs Checked Exceptions
    • Unchecked exceptions represent conditions that, generally speaking, reflect errors in your program's logic and cannot be reasonably recovered from at run time
      • Do not handle the exception, but prevent it
      • There are exceptions for this!
      • Subclasses of ‘RuntimeException’
    • Checked exceptions caused due to genuine error scenarios happened outside the control of the system
      • Connection Issues
      • Input Issues
      • Resourcing Issues
      • Subclasses of ‘Exception’
  • 8. Unchecked Exceptions: Prevent Them
        • private static int mod(int a, int b) {
        • return a % b;
        • }
    • Is it correct?
  • 9. Unchecked Exceptions: Prevent Them
    • private static int mod(int a, int b) {
    • try {
    • return a % b;
    • } catch (Exception e) {
      • logger.error(“Error in calculating mod function”, e)
    • return 0;
    • }
    • }
    • Is it Correct?
  • 10. Unchecked Exceptions: Prevent Them
    • private static int mod(int a, int b) {
    • try {
    • return a % b;
    • } catch (Throwable e) {
      • logger.error(“Error in calculating mod function”, e)
    • throw new IllegalArgumentException("Divisior can not be zero for mod operation");
    • }
    • }
    • Is it correct?
  • 11. Unchecked Exceptions: Prevent Them
    • private static int mod(int a, int b) {
      • if(0 == b){
    • throw new IllegalArgumentException("Divisior can not be zero for mod operation");
    • }
    • return a % b;
    • }
    • Unchecked exception is prevented
    • The handling part of exceptional case is not the responsibility of the method
    • Its caller’s responsibility to handle zero cases
  • 12. Unchecked Exceptions: Prevent Them
    • public static void main(String[] args) {
    • int a = 1;
    • int b = 1;
    • //read a
    • //read b
    • if(0 == b){
    • // tell user the number is not acceptable
    • }
    • int mod = mod(a, b);
    • }
    • Its over to user at the end!
  • 13. Checked exception: don't handle, but propagate back
    • public boolean isAvailable(String id) throws PipeException{
    • Object a = query(id);
    • return null != a;
    • }
    • private Object query(String id) throws PipeException;
    • It not isAvailable method's responsibility
  • 14. Checked exception: You handle it, Your Responsibility
    • try {
    • if (condition) {
    • throw new AppNotAvailableException("The recipient is null",
    • AppNException.INVALID_SHORTCODE);
    • }
    • //do something
    • targetService.execute(sdpRequestMessage, sdpMessageContext);
    • } catch (AppNotAvailableException e) {
    • sdpMessageContext = new SdpMessageContextImpl();
    • sdpMessageContext.setShortcode(shortcode);
    • e.setShortcode(shortcode);
    • exceptionHandlerService.onMessagingException(sdpRequestMessage, sdpMessageContext, e);
    • } catch (Throwable th) {
    • exceptionHandlerService.onMessagingException(sdpRequestMessage, sdpMessageContext, th);
    • }
    • }
  • 15. So Simple Haa?
    • Its simple, but we don't do simple things simple!
    • Kinda people who ship a system if it compiles!
    • Kinda people who touch our code even when TCs failing
    • Some frameworks make simple things complex
      • ORM(Spring, hibernate, JPA) exceptions are RUNTIME: Why?
      • But most of us don't know why! Result?
        • DB Connection Error at UI.
        • System at stalemate when a integrity violation happens.
        • Genuine errors causing so many troubles.
      • Some developers even don't know there can be ORM exception!
  • 16. Contd...
    • Propagating Checked Exceptions across modules creates coupling
      • Always catch and re throw module specific exception
      • public void delete(String appId) throws QueryByTransactionIdException {
    • try {
    • jdbcTemplate.update(query);
    • } catch (DataAccessException e) {
    • throw new QueryByTransactionIdException("Error while adding the TransactionStatus", e);
    • }
    • }
  • 17. Contd…
    • protected ModelAndView processFinish(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, Object command, BindException bindException) {
    • //do something
    • try { serviceLocator.getAmaFieldTypeConfigurationService().addNewAmaFieldType(amafieldType);
    • return new ModelAndView(successView);
    • } catch (MetadataException dae) {
    • getServiceLocator().getMetadataServiceManagerStub().reInitMBean();
    • bindException.reject("globle.error.meta.access.exception");
    • bindException.getModel();
    • return showPage(httpServletRequest, bindException, 0);
    • } catch (Throwable dae) {
    • bindException.reject("globle.error.unexcepected.exception");
    • bindException.getModel();
    • return showPage(httpServletRequest, bindException, 0);
    • }
    • }
  • 18. Use Finally for cleansing
    • public void dataAccessCode() {
    • Connection conn = null;
    • try {
    • conn = getConnection();
    • //some code that throws SQLException
    • } catch (SQLException ex) {
    • throw new JKException("Error while accessing data ", ex)
    • } finally {
    • try {
    • DBUtil.closeConnection(conn);
    • }
    • catch (Throwable e) {
    • //do nothing or throw RuntimeException
    • }
    • }
    • }
  • 19. Good Practices
    • Use error logging effectively
      • Genuine or Not, its our support going to struggle.
      • logger.error(“Put some valuable message”, e)
    • Always catch Throwable at the end
      • Trust nobody including you
      • Handle the checked exception and the keep a catch clause for Throwable INCASE
    • Sending traps: Be proactive & sensible
    • Keep the exception class directly under root package of the module
    • Log exception only once
  • 20. WORRY ABOUT EXCEPTIONS
    • Decide which method to handle and which one to propagate (Throw early catch late )
    • Think about the complete flow with the exception and handle it at the right place
    • Write testcases for exceptional cases
    • Spend an hour to work on the UIs with exceptional scenarios
      • Error code mapping to error pages
      • Exception class mapping to error pages
      • Error message resource bundles
      • What happens to session when this happen?
      • Should we enable back button?
      • Should we keep a home button?
  • 21. DANKE!

×