Hello. The concept used in this project is exception handling and try, catch structures. My instructor provided base code which you can see in the files I attached along with the document for the instructions. And the file that has the base code has a couple of classes in them. Wherever a "return ol" is written in the class, that is where code needs to be completed.
Thank you for your help
Objective The purpose of this assignment is to practice enums, exceptions, and unit testing. You will implement and modify a few classes that solve a programming task, and then you will write a small tester to test your code. No tester will be provided for this assignment. Overview 1. Analyze the ShapeManager class and the interface it uses, AreaCalculator. 2. Analyze the Shape class hierarchy, used to represent a limited set of shapes. 3. Analyze the enum named MeasuringUnit, used to represent the shape sides’ unit of measurement (FEET, or METER). 4. Implement the exception classes ShapeException, MeasuringUnitException and AreaCalculatorException, which shall be used to signal improper values and impossible actions relating to classes. 5. Write a class named E2Tester that performs unit testing for the classes. Background During use of the classes, sometimes we may accidentally try to feed bad values into a method. In these cases, the program should raise an exception. The unit tester should be able to verify that the code is properly signaling the illegal operations via exceptions. However, unchecked exceptions are a controversial topic. So no exception left unchecked. In Java, your API consists of the public classes and their public members (fields, methods). We will relax such requirement to checking for the following Java Unchecked Exceptions: • Null Pointer Exception (NPE) • Array Index Out of Bounds Exception (AIOBE) • Arithmetic Exception (AE) • Illegal Argument Exception (IAE) • Illegal State Exception (ISE) You will mask those unchecked exceptions within the realm of the three exceptions listed above for this exercise (ShapeException, MeasuringUnitException, AreaCalculatorException). Exception Masking is catching an exception and propagating a different one. Since, unchecked exceptions are not listed by the compiler, your code must be explicit in throwing this exercise’s exceptions Rules 1. In the E2Tester class that is using the JUnit 4 Framework, you are allowed to import and declare anything you want from the framework. 2. In the other classes, you are NOT allowed to: a. import anything or use the fully qualified path to bypass this restriction. b. add any public methods other than the ones listed in the specs below. c. add any instance/class variables (not even private) other than the ones listed in the specs below. Classes CheckedRuntimeException This abstract class serves as the backbone of all the exceptions you will need to implement. The maskedRuntimeException field must be set upon instantiation in child classes, always. Otherwise, your tests will fail during grading. You must implement the following 3 exceptions and mask the Java Unchecked Exceptions: ShapeException This masked exception should extend the CheckedRuntimeException class. It is thrown if a MeasuringUnit field within the Shape hierarchy or ShapeManager is given a null value at any point during execution. It is thrown if an integer field within the Shape hierarchy or ShapeManager is given a null value or is not a positive value at any point during execution. AreaCalculatorException This masked exception should extend the CheckedRuntimeException class. It is thrown if implemented methods of the AreaCalculator interface performs calculations that overflow the result (e.g., Integer.MAX_VALUE + 1 overflows integer values). MeasuringUnitException This masked exception should extend the CheckedRuntimeException class. It is thrown if a measuring unit field of shape is null during execution of AreaCalculator’s methods. This exception masks a specific case of the Shape Exception You must change the behavior of the following classes, so they support the MeasuringUnit enum and handle the implemented masked exceptions: NOTE: Change the behavior of code means to edit the code so it complies to a desired intent. Handling an exception means that the code enforces an exception’s scenarios correctly, either by catching the exception, propagating it, or both. You must edit the code, so it handles an exception. Implementing a method means write code that satisfies an intended behavior. For example, an interface has methods that need to be implemented. Each method description in an interface specifies a contract, the intended behavior of the method when used by others. A class that implements an interface, needs to satisfy the contract of each method in the interface ShapeManager You must implement the AreaCalculator methods. The methods are defined but not fully implemented. Make sure the shapes’ measuring units are the same as you implement the calculations. You must handle that all methods in this class catch possible unchecked exceptions and propagate the correct masked exceptions Shape You must handle that all methods in this class catch possible unchecked exceptions and propagate the correct masked exceptions. Square You must handle that all methods in this class catch possible unchecked exceptions and propagate the correct masked exceptions. Rectangle You must implement the AreaCalculator methods. The methods are defined but not fully implemented. Make sure the shape’s measuring units is based on its unit’s field. You must handle that all methods in this class catch possible unchecked exceptions and propagate the correct masked exceptions E2Tester You must write your own tester. An empty template is provided for your convenience. Be warned though that the tests in the template are empty and an empty test will naively “pass” the tester because no assert statement has failed. This is the starting point for solving the exercise, please follow the commands at the top of the file to edit-n-run your code. This does not mean that the tester is correct! You must fill in the template with actual tests before you start testing your solution. If your solution passes all the tests of your own tester, a question that arises is how good your tester is. Did you pass the tests because the solution is correct or because the tester is unable to detect any errors? To verify that your tester is good, make a backup of your code and then start introducing bugs to your solution. For every bug you create, use your tester to check if it can detect the failure. The more defects it detects the better the tester is. Be sure to make tests for each class’s method, inspect them one-by-one and line-by-line, it will help you notice where exceptions may arise. Your tests should be able to handle exceptions and normal program execution. Now, Gotta Catch ’Em All How my project will be graded: Grading has two parts with 50-50 weight: 1. To grade your solution, we will use our own tester that, unlike previous assignments, is not provided to you for obvious reasons. 3. To grade your tester, we will use a defective version of the solution and we will count how many bugs your tester can detect. The more errors your tester finds the higher your score will be. 4. a. If your program throws any exception other than the ones masked by you, that is, they do NOT extend CheckedRuntimeException, points will be deducted. b. If you are handling exceptions unrelated to the code at hand, points will be deducted. Each unrelated exceptions weights double than a correct one, be cautious. I put extra information on how my project will be graded. Please make the program so that the tester detects the most number of bugs.