aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes some odd answers from the K&B CD Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "some odd answers from the K&B CD" Watch "some odd answers from the K&B CD" New topic
Author

some odd answers from the K&B CD

John Schubert
Ranch Hand

Joined: Sep 21, 2011
Posts: 39

Hi guys. I hope some of you could explain me what to do when facing this kind of subjective questions. I'll post some answers that really surprised me (and screwed my score on the tests ). They're from the K&B 6 CD.

NullPointerExceptions and ArrayIndexOutOfBoundsExceptions are not typically thrown by developers, but by the JVM.

Well, as a programmer, I've coded tons of NPEs and AOOBEs, for instance on libraries or utilities. As result of this "bad habit" of mine, I missed the correct answer (which was that only NumberFormatExceptions are typically thrown by developers). I'm of the opinion that throwing these two exceptions are common practice, and that such a question should not appear on tests.

Another one:
is-a relationships always rely on polymorphism.

This is very confusing, since you can code a hierarchy of classes without overriding any method, so no polymorphic calls are actually used.

The last one:
Coupling is not used to evaluate classes within the same inheritance tree.

Well, excuse me, but coupling is a broad concept that applies even to modules. If we consider the classes as modules, we could see that as subclasses depend on the intern logic of the superclasses, they are Tightly Coupled to their ancestors.

What's your opinion? Are there some rules to get the "correct" (test passing) point of view? Or it is that these questions are simply too subjective?


fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11406
    
  16

I am not an expert but here is my 2-cents...

I don't think I (and i doubt you) have ever written code like:

you have never written code that EXPLICITLY throws the exception. Sure, you code may throw one, but only when the JVM checks the variables.


You may not override the methods, but you can still have a reference type that is of a super-class pointing to a sub-class object. This still relies on polymorphism.


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18655
    
    8

John Schubert wrote:
is-a relationships always rely on polymorphism.

This is very confusing, since you can code a hierarchy of classes without overriding any method, so no polymorphic calls are actually used.


But polymorphism doesn't require method overriding. Consider this: suppose you write a Java class, and allow it to extend Object. Even if your class doesn't override Object's toString() method, it still inherits that method. From Wikipedia:

Wikipedia wrote:In computer science, polymorphism is a programming language feature that allows values of different data types to be handled using a uniform interface.


So, the "interface" in this case is that defined by the Object class; the class you wrote can be handled by that interface, since it implements all of the methods declared by Object. It doesn't matter that it fails to override any of them.
John Schubert
Ranch Hand

Joined: Sep 21, 2011
Posts: 39

fred rosenberger wrote:
you have never written code that EXPLICITLY throws the exception. Sure, you code may throw one, but only when the JVM checks the variables.


I did XD. A quick search over last two years projects in my dev. machine yields 33 matches for ArrayIndexOutOfBoundsException, mostly on GUI classes (fixed width managers). I can find it also in open source libraries like ZXing. What to say about NPE, they are just ubiquitous. So I don't buy that. It is a tool the programmer can use and it can't be assumed that only the JVM throws it.

About the polymorfism, you may be right there. But as I was reading it, I found the "always rely" part too categorical.
dennis deems
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
John Schubert wrote:
fred rosenberger wrote:
you have never written code that EXPLICITLY throws the exception. Sure, you code may throw one, but only when the JVM checks the variables.


I did XD. A quick search over last two years projects in my dev. machine yields 33 matches for ArrayIndexOutOfBoundsException, mostly on GUI classes (fixed width managers). I can find it also in open source libraries like ZXing. What to say about NPE, they are just ubiquitous. So I don't buy that. It is a tool the programmer can use and it can't be assumed that only the JVM throws it.


What is the point of writing



???
John Schubert
Ranch Hand

Joined: Sep 21, 2011
Posts: 39

Dennis Deems wrote:
What is the point of writing

???


When I'm developing some utility class or library, I use to do this:


In a perfect world, the client programmer performs null-validation prior calling my method, but that's not how things work. The more info, the better. In development machines we have the stacktrace, but outside the dev. environment, a good exception message helps to quickly identify the problem.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18655
    
    8

Dennis Deems wrote:What is the point of writing

???


The point of that is to tell your method's caller that some variable was null which shouldn't have been null, and that it was an unexpected occurrence, and that it was probably the caller's fault.
dennis deems
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
Dennis Deems wrote:What is the point of writing

???


John Schubert wrote:
When I'm developing some utility class or library, I use to do this:


In a perfect world, the client programmer performs null-validation prior calling my method, but that's not how things work. The more info, the better. In development machines we have the stacktrace, but outside the dev. environment, a good exception message helps to quickly identify the problem.


It seems to me that in this case an IllegalArgumentException would be more appropriate.

Paul Clapham wrote:The point of that is to tell your method's caller that some variable was null which shouldn't have been null, and that it was an unexpected occurrence, and that it was probably the caller's fault.


But the JVM will do all this for free, without fail, when my method attempts to interact with the null object.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18655
    
    8

Dennis Deems wrote:
Paul Clapham wrote:The point of that is to tell your method's caller that some variable was null which shouldn't have been null, and that it was an unexpected occurrence, and that it was probably the caller's fault.


But the JVM will do all this for free, without fail, when my method attempts to interact with the null object.


Indeed it will. But that leaves the poor schlub looking at the stacktrace and asking himself "Why is File.listFiles throwing a NPE?" when three levels up is your method which could have detected that null and thrown a NPE. So yeah, there's no cost to you as the programmer; you just shifted the cost over to the user in the form of a decrease in clarity.
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11406
    
  16

NullPointerExceptions and ArrayIndexOutOfBoundsExceptions are not typically thrown by developers, but by the JVM.

Note that this says "not TYPICALLY thrown by developers". You are the first developer I've ever heard of that explicitly throws them. Not that who I have spoken to is a representative sample by ANY means...

It seems to me like you are saying "Well, I throw them, therefore this statement is wrong." I would say that you alone are also not a representative sample.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18655
    
    8

It depends what kind of code you're writing. If you are writing application code, then you can leave it to the JVM to catch your sloppy null-handling, and it won't really matter because you or your co-workers are the ones dealing with the problem. However if you're writing library code which is going to be used by other people -- like if you're somebody like Apache -- then what I just replied to Dennis a little while ago applies, I think. You're in the same category as the JVM writers -- you and they both write code for complete strangers to use.

Although I've used plenty of libraries where the authors didn't take my advice, and instead blindly passed nulls along until some obscure internal component finally threw a NPE. That just makes it harder to debug, since you have to work backwards and figure out that you accidentally passed null as the fourth parameter of some library method.
dennis deems
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
Paul, in my opinion, where you are advocating the use of NullPointerException, it would be more appropriate to throw an IllegalArgumentException, and more congruent with your rationale for throwing the exception in the first place. I assume, given your concern over your consumer's potential state of bafflement, your method is supplied with javadoc that tells me in no uncertain terms that I must not pass a null argument. I assume further that your doc gives me a clear understanding of what is going to happen to my parameter after I pass it to you. As a developer, I expect an IllegalArgumentException when I pass an illegal parameter. I expect a NullPointerException when attempts are made to call methods or access fields on null. Throwing NPE in other situations would seem only to deepen the potential confusion.

I find the scenario of the developer who is stymied by the stack trace and doesn't understand why his null value causes a NullPointerException to be thrown a little hard to take seriously.
John Schubert
Ranch Hand

Joined: Sep 21, 2011
Posts: 39

fred rosenberger wrote:
Note that this says "not TYPICALLY thrown by developers". You are the first developer I've ever heard of that explicitly throws them. Not that who I have spoken to is a representative sample by ANY means...

It seems to me like you are saying "Well, I throw them, therefore this statement is wrong." I would say that you alone are also not a representative sample.


I think in the TYPICALLY is where the trap is, and of course I failed because I use to throw NPEs. But I tend to think that, even if it were not a good practise -thats another discussion - it is actually typical. You can do a search in Google and see that there are other freaks like me out there XD.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18655
    
    8

Dennis Deems wrote:Paul, in my opinion, where you are advocating the use of NullPointerException, it would be more appropriate to throw an IllegalArgumentException, and more congruent with your rationale for throwing the exception in the first place.

I wouldn't argue with that.
I find the scenario of the developer who is stymied by the stack trace and doesn't understand why his null value causes a NullPointerException to be thrown a little hard to take seriously.

I see that particular scenario quite regularly when answering questions on Java forums. Sure, it's usually beginners who are subject to that confusion, but I'm in favour of making things easier for beginners rather than harder.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: some odd answers from the K&B CD