1 / 29

Understanding and Handling Errors in Java Programming

This chapter explores the three main types of errors in programming: syntax errors, semantic errors, and runtime errors. It discusses how to deal with runtime errors by logging, warning users, or aborting the program. The chapter also covers Java's exception handling mechanism, types of exceptions, and best practices for handling them, such as using try-catch blocks and the finally keyword. Additionally, it explains checked vs. unchecked exceptions, re-throwing exceptions, and creating custom exceptions in Java to manage unique error conditions effectively.

cale
Télécharger la présentation

Understanding and Handling Errors in Java Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 13 Exceptional Programming

  2. Three kinds of errors • Syntax errors: code that does not conform to the language specifications and must be corrected to compile at all (bad programmer) • Semantic errors: code that compiles and runs but the program does not do what was intended (bad algorithm) • Runtime errors: something about the data prevents continued operations (bad data)

  3. Dealing with runtime errors • Ignore them • Log them • Warn the user/caller • Correct the error • Force the user/caller to handle the error • Abort the program

  4. Dealing with runtime errors • Ignore them • Log them • Warn the user/caller • Correct the error • Force the user/caller to handle the error • Abort the program • Java forces error handling using exceptions

  5. An unassuming program

  6. A naïve outcome

  7. A bad outcome

  8. What to do? Throw up! • But then the calling program has to handle the exception

  9. And the caller must catch

  10. Do something better

  11. Another approach

  12. Perhaps we can do better?

  13. Customizing exceptions

  14. Types of Exceptions • All exceptions ultimately derive from the Throwable class, which extends Object • Exceptions are divided into two classes that extend Throwable: Exception and Error • Subclasses of Error are typically system errors (and generally fatal to the program) • Subclasses of Exception are typically program errors

  15. Exception class subtypes • Exception is extended by many subclasses • Two commonly encountered examples are IOException and RuntimeException • RuntimeException has many subtypes, including ArithmeticException, NullPointerException, IndexOutOfBoundException, and IllegalArgumentException

  16. Unchecked Exceptions • Exceptions come in two varieties: checked and unchecked • Unchecked exceptions can be thrown anywhere in the code • Consequently, Java does not require declaring these types of exceptions • Unchecked exceptions are Error and RuntimeExction

  17. Checked Exceptions • All other exceptions are checked exceptions • Checked exceptions must be declared by the method they are thrown from • The calling method may ignore exceptions, but this is poor programming practice (but that does not mean it is uncommon) • Exceptions are declared using the throws keyword in the method declaration

  18. Example of multiple exceptions

  19. Handling priority • An exception will be caught by the first catch block that matches the exeption • Therefore, a superclass catch block will handle an exception if placed before the subclass catch block • The subtype catch blocks should be placed before the more general supertype catch blocks

  20. Overriding and Exceptions • If the supertype method does not throw a particular exception, a derived class cannot override the method and declare the additional exception

  21. What’s in an exception? • getMessage() // the error message • toString() // concatenates the fully-qualified name of the exception class : getMessage() string • printStackTrace() // prints the stack trace to the console • getStackTrace() // returns an array of stack trace elements representing each call level

  22. Last but not least: finally • The code in the finally block is executed no matter what happens in the try block • If no exception occurs, the finally block gets executed after the try block • If an exception occurs, the finally block gets executed after the exception’s catch block • If an uncaught exception occurs, the finally block gets executed

  23. Re-throwing exceptions • A catch block can re-throw an exception • Typically this would happen if the handler discovered it could not fully process the exception for some reason • The exception then passes to the calling method and must be caught/handled there • The finally block will still execute…because it executes no matter what happens

  24. Chaining exceptions • New exceptions can be created to add information to an existing exception • The two parameter constructor is used to create the new exception • The new exception is thrown similar to the way an exception is re-thrown • The calling method will receive the new exception with additional information

  25. Chained exception output

  26. Custom Exceptions • Custom exceptions can be created by extending any suitable exception class in the hierarchy • Java provides a cornucopia of exceptions to cover a panoply of error conditions • There are legitimate situations where custom exception classes could be useful • Try to avoid being in any of those situations

More Related