.. (לתיקייה המכילה) | ||
The assignment description mentions that if the enforced target method throws an exception, is should be passed to the user. Since the exception thrown by Method.invoke() is InvocationTargetException, getTargetException() should be used to obtain the original exception. However, getTargetException() returns a Throwable. Can that Throwable be cast to an Exception? | |
Yes, you can safely cast the Throwable to an Exception. Throwables are only used on extreme cases, and they will not be used in the assignment. |
Can methods running during the conditions change the state of the object? If so, should we backup the object before or after checking the precondition? | |
You can assume that the methods that are run in the conditions (not the target method) have no side effect. Namely, they will not change the target object's state. Therefore, it's safe to do the backup after checking the precondition. |
Adding the Error class to the conditions annotations raises some serialization warning. How should we deal with it? | |
Choose one of the options Eclipse suggests - either add the ID field, suppress the warning or just leave it. We won't be using serialization in this assignment anyway, so it doesn't matter. |
The method Operator.check accepts a Comparable<Object>. How can we cast the objects we want to check to this Comparable? | |
You can use a straightforward cast - (Comparable<Object>)obj. You can either check if the object's class implements Comparable first, or just handle the cast exception. This part of the code uses generics, which you haven't learned yet and are not expected to know. Keep it simple - you should be able to recognize the case where two objects are not comparable (just try to compare, and see if it throws), and you should be able to use compareTo. |
The JUnit tests won't compile. What are we missing? | |
When you use Eclipse to create unit tests, it automatically adds the JUnit library to the project. If you want to rely on the given tests file, you have to manually add the library: 1. Right-click on the project's "folder" in the package explorer. 2. Go to Build Path -> Add Libraries 3. Choose JUnit, and then JUnit 4 (not 3) on the next screen. |
What should we do if the target method does not exist? | |
This scenario has not been explicitly specified, so it won't be tested. Ideally, you should throw an IllegalArgumentException in that case. But as said, you may assume the target method always exists. |
We get the target method's arguments as an array of objects. If one is an Integer, should we look for a method that takes either an int or an Integer? | |
You may assume the target methods used for testing will not get primitive types. So, if you get an Integer argument, look for a method that accepts an Integer. |
How should we handle the backup of final fields? | |
You may assume the target objects will have no final fields, so you don't have to deal with that when restoring an object. |
The assignment's description mentions the annotation values should be named Arg1Type, Arg1Name, Operator etc., all starting with an upper case letter. The provided tests, however, use names starting with a lower case letter. Which one's right? | |
That's a documentation error. The values names should start with a lower case letter, as used in the provided test code. However, given the time of this error's discovery, both cases will be used when testing your submissions. |
What should we do in case a method that is run as part of a contract throws an exception? Should it be considered an illegal contract or contract failure? | |
Basically, that should be considered an illegal contract. However, this scenario will not be tested, and methods run as part of a contract will not throw. |
How should we tread fields and methods that return null when checking a contract? | |
By definition, null equals nothing (when using the equals() method), so this case can be considered a contract violation. On the other hand, a null value won't allow reflection operations, so it can also be considered an illegal argument. Since this wasn't specified in advance, you may assume fields and methods won't return nulls when run in a contract. This edge case won't be tested. |