OOP Tirgul 7

What We’ll Be Seeing Today  Packages  Exceptions  Ex4 2

Packages

 Packages allow you to group together related classes, like “folders” for classes.  Packages make it easier to:  Be aware of all the classes relating to the same purpose.  Solve conflicting names.  Additionally, packages play a role in access permission between classes.

Creating packages  The first line of every source file (*.java) should start with a package statement (one statement in each file). package package.subpackage;

Creating packages  Two ways of using code from another package:  Importing a Package Member import vehicle.Car;  Importing an Entire Package import vehicle.*;

Grouping related classes Vehicle CarTrainPlaneBicycleBike

Grouping related classes Now the user can easily know which Vehicle implementations are available.

Solving name conflicts  Let’s say you’ve got two classes:  Driver: Represents a vehicle driver.  Driver: Represents a computer driver.  We’ll get a compilation error if we’d try to compile both classes in the “same package”.  This, however, will work:

Solving name conflicts Will this work?

Solving name conflicts To distinguish between the two we must use the fully qualified name.

Solving name conflicts

Packages: Permissions  Do you remember the protected access modifier?  Protected fields can be accessed by:  Subclasses.  All the classes that share the same package.

Packages: Permissions

Compilation Error!

Packages: Permissions  What if there is no modifier? No modifier

Exceptions

 Exceptions are messages that state that something went wrong.  Exceptions are implemented as Java objects.  As such, fields and methods play a different role in exception classes:  Usually, the calling class knows what the message is by the specific exception class.  Each type of message has its own class.

Exceptions  Sometimes an exception object will specify more information (usually for debug purposes) such as a string specifying what exactly went wrong.

Motivation What if this line fails? What if this line fails?? What if this line fails??? What if this line fails???? What if this line fails?????

Motivation

 Reason #1 to use exceptions: Separating Error-Handling Code from "Regular" Code

Exception class hierarchy Throwable ExceptionError checked unchecked RunTimeException

Exception classes  Use existing exceptions when appropriate.  New exception classes that we write will almost always be checked;  I.e., extend the Exception class.  Must be caught or declared as thrown.  Exception classes that we write may have their own hierarchay;  Allows treating several types of errors similarly.

Unchecked exceptions  Represent problems that are the result of a programming problem:  Arithmetic exceptions (dividing by zero)  Pointer exceptions (accessing a null reference)  Indexing exceptions (accessing an array element with an out-of-bounds index)  Calling code cannot be expected to recover or handle them.

Defining new Exception classes Out of milk Class Coffee Vending Machine Out of coffee Out of sugar getDrink() getCoffee() getLatte()

Defining new Exception classes public class LatteException extends Exception{ private static final long serialVersionUID = 1L; public LatteException () { super(“Problem with ordering coffee”); } public LatteException (String s){ super(s); } Default Ctor Message Ctor What’s this? At the moment: 1.Write this (“1L”) in every Exception class. 2.Prevents an annoying warning. 3.We’ll learn about it in week 12.

Throwing Exceptions Latte getLatte() throws LatteException { if (milk.isEmpty() || suagr.isEmpty()) throw new LatteException (); }

Using Exception Hierarchy Exception LatteException OutOfMilkException OutOfSugarException

Using Exception Hierarchy class LatteException extends Exception{…} class OutOfMilkException extends LatteException {…} class OutOfSugarException extends LatteException {…} private Latte getLatte() throws LatteException { if (milk.isEmpty()) throw new OutOfMilkException (); if (suagr.isEmpty()) throw new OutOfSugarException (); //... } Why throw an exception instead of handling it? 1.It’s unexpected (for this method, anyway). 2.It’s rare. 3.Only some specific calling function should and/or could handle this exception.

Catching Exceptions Public getCoffee(){ try{ // Making Latte Latte l = getLatte(); //... } catch(LatteException e){ checkLatteSystem(); } getDrink() getCoffee() getLatte()

Catching Exceptions Public getCoffee(){ try{ // Making Latte Latte l = getLatte(); //... } catch(OutOfMilkException e){ orderMilk(); } catch(LatteException e){ handleGeneralLatteExceptions(); { } getDrink() getCoffee() getLatte()

Motivation  Reason #2 to use exceptions: Grouping and Differentiating Error Types

try{ // Making Latte Latte l = getLatte(); //... } catch(LatteException e){ //... } catch(OutOfMilkException e){ //... } What’s Wrong Here? Compilation Error! OutOfMilkException OutOfSugarException LatteException

Exception Declaration  Each method must declare the checked exceptions it throws. public Latte getLatte() throws LatteException { if (milk.isEmpty()) throw new OutOfMilkException (); if (suagr.isEmpty()) throw new OutOfSugarException (); //... }

Exception Flow Out of milk Class Coffee Vending Machine Out of coffee Out of sugar getDrink() getCoffee() getLatte()

Exception Declaration  “Translating” Exceptions from one class to another through encapsulation. try{ //call some Latte method }catch(LatteException e){ throw new BadDrinkException("problem", e); } Latte Coffee e1 e2 Call 1 Call 2 Drink Preserving the full stack trace

Motivation  Reason #3 to use exceptions: Propagating Errors Up the Call Stack

Handling several types of Exceptions  If we want to catch more than one exception but handle them all in the same way, we can use the “|” operator try { // Making Latte Latte l = getLatte(); //... }catch(Exception1|Exception2 e){ // Handle Exception1, Exception2 in the same way e.getMessage(); }

Exceptions and Packages  Exceptions should be put in the same package as the classes that throws them  And not all in the same package  IOException resides in java.io  EmptyStackException resides in java.util  This is because exceptions are logically connected to the classes that throw them  More than they are connected to one another

Bad usage of Exception Handling  Using a computer language's error handling structures to perform normal program logic. try { int idx = 0; while (true) { displayProductInfo(prodnums[idx]); idx++; } } catch (IndexOutOfBoundsException e) { // Do some cleanup } Heavy! Unexpected! Hides bugs!

Ex4

 You will implement an AVL Tree, according to some API we will give you.  You don’t get any code from us.  A great way to make sure you not only understand some specific DaSt subject, but also know how to implement a theoretical data structure.