Advanced Java Course Exception Handling Throwables Class - PowerPoint PPT Presentation

Advanced Java Course Exception Handling

Throwables • Class Throwable has two subclasses: – Error • So bad that you never even think about trying to catch these – Exception • Most Exceptions must be handled (i.e. either declared in the method’s throws clause or caught) • Except Runtime Exceptions, which are “unchecked” – they don’t have to be declared

Syntax of Exception Handling • To throw: <<return_type>> <<method_name>>(<<args>>) throws <<ExceptionType>> { <<calls to methods that have declared Exceptions in their throws clauses are in the body of this method.>> } • To catch: <<return_type>> <<method_name>>(<<args>>) { try { <<calls to methods that have declared Exceptions in their throws clauses are in the body of this try statement.>> } catch (<<ExceptionType>> <<exceptionVariableName>>) { <<here you can report the exception, and recover from it.>> } }

When to do what? • If code that your code calls declares that it can throw an Exception, what should you do? – Just throw the exception – Catch the exception, report it, and recover – Catch the exception, make a new, different exception, and throw the new one • When do you throw an Exception even if no Exception was thrown to you?

When to re-throw the Exception • If it’s more appropriate to deal with it at a higher level of the code. • If the exception means death to the method it’s in. In other words, there’s no reasonable way you can continue to execute the code of this method

When to catch it and recover • If this is the appropriate place to report the exception to the user, or log it, or whatever you plan to do with it. • If you can and should continue with this method – for example if you can use a default value, or try again.

When to catch it & throw your own • You’re sure the Exception that must be handled is impossible (if your code is correct), so you don’t want to have to declare it all the way up. On the other hand, if your code is incorrect, you should not “hide” the exception – you need to see it so that you can fix your programmer error. Throw a new RuntimeException. • You want to create an abstraction layer, and hide the implementation. Throw a new instantiation of your own Exception class.

When to create your own Exception • Sometimes you might create a new Exception instance even though none of your code threw one to you. You might be the first “thrower” of this Exception. • You should do this if your code detects some error state that you cannot recover from in this method – for example, an input might be of an illegal value.

Why you might need a new Exception subclass • If you’re creating a new framework, or library, chances are you’ll want Exceptions that ‘fit’ within that framework, and are descriptive off it. This is part of creating that abstraction layer. • You want added functionality, like the ability to wrap an Exception around another, so that you can create the abstraction layer without totally destroying the information of what’s below it.

Abstraction Layer? • Abstraction Layer (mentioned in the previous slide) – When you implement a new Type, and you want to hide the implementation from the user of your new type, so that they don’t have to worry about how you did it. – Biology metaphor: my body produces an abstraction layer so that when I shake someone’s hand, they don’t have to worry about how I did it. – When you create a class Graph in Java, for example, the person using the Graph shouldn’t need to know whether you used Arrays or Vectors or something else to implement it. Creating your own Exceptions is part of this.

Checked or Unchecked? • If you create your own new Exception class, should it be checked or Runtime? – RuntimeExceptions are for programmer error – i.e. your code is in a state it just oughtn’t be in, and it’s a really bad state. Stop program execution and go debug. By the time a program reaches an end-user, it should never throw these. The outermost layer of your program should gracefully catch all Exceptions, even Runtimes and do something user-friendly. – Checked exceptions (all Exceptions other than RuntimeExceptions) are for dealing with the outside world. If something about the input the user gave you is bad, or a file is corrupt, or a database server is down, these are real-life things that could happen, and your program should cope with them as gracefully as possible.

Summary of Exceptions • Catch and hide an exception if – Can recover: (default value, user try again) • Re-throw an exception if – Irrecoverable to method – More appropriate to handle elsewhere • Throw new if – Building abstraction layer – Want to throw unchecked runtime exception

Summary of Exceptions • When creating your own exception class – Name it descriptively – Place appropriately in class heirarchy – If programmer error, make it a subclass of RuntimeException (so it’s unchecked) – If outside error (network, user, etc.), make it a checked Exception