About Question enthuware.ocajp.i.v7.2.1030 :

Help and support on OCA OCP Java Programmer Certification Questions
1Z0-808, 1Z0-809, 1Z0-815, 1Z0-816, 1Z0-817

Moderator: admin

Post Reply
aleksjej
Posts: 2
Joined: Mon Jun 16, 2014 5:04 pm
Location: Gdansk/PL
Contact:

About Question enthuware.ocajp.i.v7.2.1030 :

Post by aleksjej »

In exception class summary we can read that the AssertionError is thrown by JVM, not by the programmer explicitly so how is that possible that in the first case AssertionError is better choice than IllegalArgumentException? Thanks

admin
Site Admin
Posts: 8996
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by admin »

It is true that AssertionError is thrown by the JVM when an assertion fails. But a programmer can throw it explicitly as well for situations that he assumes will never occur. In this case, he knows that suit can never have any other value, it is therefore appropriate for him to throw AssertionError. It is same as using assert statement in situations where the programmer knows that something will definitely be true.

IllegalArgumentException is thrown by the programmer when he knows that the method may be called with illegal arguments by someone else.

The terminology "thrown by the JVM" and "thrown programatically or by the application" is not precise but is used by popular books. If it helps, you can think of the exception categories as "thrown implicitly" and "thrown explicitly". An exception that is thrown even when there is no throw statement, is said to be thrown implicitly. For example, calling a method on null will cause a NullPointerException to be thrown automatically, even though there is no throw statement. On the other hand, a code may throw an exception explicitly by using the throw statement. For example, a method code might check an argument for validity and if it finds the argument inappropriate, it may throw an exception by executing throw new IllegalArgumentException();.


HTH,
Paul.
If you like our products and services, please help us by posting your review here.

mutley
Posts: 6
Joined: Mon Feb 23, 2015 9:37 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by mutley »

I understand your answer from a point of view , but I do not find it an absolute answer . Let me explain :
Since that Enum ONLY has 4 elements , would it be wrong to assume that another state would mean an IllegalState of that object?

So why one cannot throw an IllegalStateException ?

admin
Site Admin
Posts: 8996
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by admin »

It is a bit subjective and so there is no absolute answer. Yes, you have a valid point for an IllegalStateException. On the other hand, the state of object which contains the given switch statement is not illegal. The state of the suit object is illegal because the suit object contains an extra value for the enum. So from that perspective, IllegalStateException may not be so valid.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

winddd
Posts: 18
Joined: Wed Feb 11, 2015 10:48 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by winddd »

Enum can be extended. Throwing AssertionError instead of using assert - unacceptable. Using assert in this situation - unacceptable.

admin
Site Admin
Posts: 8996
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by admin »

winddd wrote:Enum can be extended.
No, they can't be extended (in Java, at least).
Throwing AssertionError instead of using assert - unacceptable. Using assert in this situation - unacceptable.
Perfectly valid because of above.

On a side note, even if you were able to extend an enum, your switch statement wouldn't compile if you had case values not belonging to the enum of your switch variable.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

winddd
Posts: 18
Joined: Wed Feb 11, 2015 10:48 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by winddd »

admin wrote:No, they can't be extended (in Java, at least).
CAN. Teamwork. New enum elements can be added without notice. Programmer always has to consider such opportunity.
Last edited by winddd on Wed Feb 25, 2015 12:53 pm, edited 1 time in total.

winddd
Posts: 18
Joined: Wed Feb 11, 2015 10:48 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by winddd »

Moreover, raising an exception is admissible in certain cases, it can be both IllegalArgumentException, and IllegalStateException, depending on a context.

admin
Site Admin
Posts: 8996
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by admin »

Hence the use of assersions. Assertions are used for conditions that the programmer has assumed to hold true. If any such condition changes, it should be found out during development When assertions are enabled. Here, the question clearly mentions that there are no other values in the enum. Therefore, usage of assertion is valid.

By your logic, any code can be changed, so why use assertions at all?
If you like our products and services, please help us by posting your review here.

admin
Site Admin
Posts: 8996
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by admin »

winddd wrote:Moreover, raising an exception is admissible in certain cases, it can be both IllegalArgumentException, and IllegalStateException, depending on a context.
Not acceptable in this situation because any other value for enum is not possible.
If you like our products and services, please help us by posting your review here.

winddd
Posts: 18
Joined: Wed Feb 11, 2015 10:48 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by winddd »

admin wrote:By your logic, any code can be changed, so why use assertions at all?
correct use of asserts:

Code: Select all

int i = 10 / 2; assert i == 5 : "crazy jvm";
And never raise AssertionError manually.
admin wrote:Not acceptable in this situation because any other value for enum is not possible.
Other values for enum is always possible. Integer > 2147483647 - not possible, String.length() < 0 - not possible. Fixed enum contents - not possible, as it not typical. SomeObject.applyState(stateEnum) throwing AssertionError? SomeObject.executeCommand(stateEnum) throwing AssertionError? It's ridiculous.

admin
Site Admin
Posts: 8996
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by admin »

I am sorry but I don't agree with your argument. Here is a statement straight from the official oracle's tutorial
Assertions, however, should be used to check for cases that should never happen, check assumptions about data structures (such as ensuring that an array is of the correct length), or enforcing constraints on arguments of private methods.
If you restrict the use of assertions to the kind of cases that you've mentioned i.e. Integer > 2147483647 or String.length() < 0, you are basically just adding redundant useless code. If you can't depend on the fact that an int will not be greater than 2147483647, you might as well pick another JVM or platform altogether.

thank you,
Paul.
If you like our products and services, please help us by posting your review here.

winddd
Posts: 18
Joined: Wed Feb 11, 2015 10:48 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by winddd »

admin wrote:I am sorry but I don't agree with your argument. Here is a statement straight from the official oracle's tutorial
Find though one recommendation to throw AssertionError manually.

winddd
Posts: 18
Joined: Wed Feb 11, 2015 10:48 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by winddd »

Assertions, however, should be used to check for cases that should never happen, check assumptions about data structures (such as ensuring that an array is of the correct length), or enforcing constraints on arguments of private methods.
Exactly. New enum elements - not that case.

admin
Site Admin
Posts: 8996
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by admin »

I think you are misinterpreting the statement. It doesn't just stop after "check for cases that should never happen". The remaining part gives example that make it clear what they mean. Using assertion to check for int > max int is insane.

It is certainly preferable to use the assert statement instead of explicitly throwing but that is not the point of this question. The point is to check the assumptions about the code using assertions from an exam point of view. Switch statement on an enum itself is not a good practice but that doesn't make the whole question invalid from the exam point of view.

On page 157, Effective Java Second edition gives a similar example, where throwing an AssertionError is appropriate -

Code: Select all

// Switch on an enum to simulate a missing method
public static Operation inverse(Operation op) {
  switch(op) {
    case PLUS: return Operation.MINUS;
    case MINUS: return Operation.PLUS;
    case TIMES: return Operation.DIVIDE;
    case DIVIDE: return Operation.TIMES;
    default: throw new AssertionError("Unknown op: " + op);
  }
}
Anyway, I guess we will have to agree to disagree here.

thank you,
Paul.
If you like our products and services, please help us by posting your review here.

winddd
Posts: 18
Joined: Wed Feb 11, 2015 10:48 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by winddd »

It is a pity that such examples are published in books, but such code is absolutely invalid. It is the point of view of the java-programmer with fifteen years' experience. In my opinion this question should be overworked to exclude AssertionError.

jayallenloew
Posts: 6
Joined: Mon Jun 29, 2015 8:41 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by jayallenloew »

enthuware.ocajp.i.v7.2.1030

Good discussion. Here is the truth about this question.

As some have correctly noted, the default case statement will never be entered given the enum as written. It could be compared to:

final int a = 100;
final int b = 1000;
if(a>b) {
// do something
}

As you can see, the if condition will never evaluate to true, the code will never be executed, and so the entire conditional statement is legal but unnecessary.

But giving a switch statement a default case, even when of type enum, is part of defensive programming, and is probably a good idea.

Lastly:
a) Explicitly throwing Error, or any of its subclasses such as AssertionError, is normally a bad idea.
b) Throwing AssertionError in this context is far from a slam-dunk, and can rightly be challenged. This question should be either rewritten or withdrawn.

admin
Site Admin
Posts: 8996
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by admin »

jayallenloew wrote: As some have correctly noted, the default case statement will never be entered given the enum as written. It could be compared to:

final int a = 100;
final int b = 1000;
if(a>b) {
// do something
}
No, it is not the same. Here, a and b are final. In case of enum, no one prevents you from adding another element to the enum. That is what the default case is meant to prevent against.
If you like our products and services, please help us by posting your review here.

skippy
Posts: 2
Joined: Wed Aug 26, 2015 8:32 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1030 :

Post by skippy »

To quote the javadoc for Error
An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it.
A method is not required to declare in its throws clause any subclasses of Error that might be thrown during the execution of the method but not caught, since these errors are abnormal conditions that should never occur. That is, Error and its subclasses are regarded as unchecked exceptions for the purposes of compile-time checking of exceptions.
This means that if i had a enum that only had 4 valid cases that is being used in 1000 places and one of those places has an assertion error, it might bring down my whole application if at some point someone adds a new enum and it calls that code. It doesn't matter that just one out of the 1000 requests ever reaches that code, instead of inconveniencing one guy, we'll inconvenience everyone by shutting down the entire application.

I would definitely throw a illegal argument exception in this case.

computeDiscount(CustomerType.WEIRD_GUY) is not a serious problem

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 1 guest