Win a copy of Escape Velocity: Better Metrics for Agile Teams this week in the Agile and Other Processes forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Paul Clapham
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Frank Carver
  • Junilu Lacar
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • fred rosenberger

how to know when unshown, preceding code is assumed correct and complete?

 
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I really hope that the format of questions in the real exam is better than in The book (SCJP 6 by Sierra and Bates).
Now it's not possible to answer correctly to all questions. Correct answers depens on whether given code was complete or whether *some* code had to precede the given one.

For example on page 409 question 15


Correct answer is D, This is because IOException wasn't imported. So the given code wasn't complete. (Also the line number isn't correct?) BUT simultaneously following question #9 exist on page 777


The "correct" answer HERE is G. (although I can't compile such code) So the code is not considered complete, opposite to previous question. How should one know when code is complete and when not? From my point of view there are two possible combinations of correct answers here:
- All code IS complete
----> #15 answer is correct
----> #9 answer is not correct (won't compile)
- All code IS NOT complete
----> #15 answer is not correct (B would be correct)
----> # Answer is correct

It's not possible to know when given code on question is considered complete, or then it should be explicitly mentioned, which is not the case here
 
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm pretty sure the K&B book does specify this somewhere. The important thing are the line numbers in the listing given (which you've omitted here). If the line numbers start from 1, then you know there's nothing else preceding the code shown. If they start with anything else, then you know that there is code preceding it (and that exactly what that code is is not the point of the question).
 
author
Posts: 9046
21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Tapio,

Thanks so much for your encouraging words

As Matthew said, if the line numbers start at line 1, you know it's a complete file. If they start with a higher number than you are to assume the unseen code is correct. And, by the way, we discuss this on page XXX in the intro.

hth,

Bert
 
Master Rancher
Posts: 4280
57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tapio Niemela wrote:
Correct answer is D, This is because IOException wasn't imported. So the given code wasn't complete.


No, that's not the reason. Even if we assume IOException was imported in code not shown (and that's what I would assume, but we can't tell in your example), the code with "throws IOException" will not compile. That's because (a) IOException is a checked exception, and (b) in the code shown, which is the complete class Frisbee including method main(), there is no code that could possibly throw an IOException. Even if it were imported. If you declare a method throws a checked exception, and the compiler can see that there's nothing that could throw that checked exception, that's a compile error.
 
Tapio Niemela
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mike Simmons wrote:

Tapio Niemela wrote:
Correct answer is D, This is because IOException wasn't imported. So the given code wasn't complete.


No, that's not the reason. Even if we assume IOException was imported in code not shown (and that's what I would assume, but we can't tell in your example), the code with "throws IOException" will not compile. That's because (a) IOException is a checked exception, and (b) in the code shown, which is the complete class Frisbee including method main(), there is no code that could possibly throw an IOException. Even if it were imported. If you declare a method throws a checked exception, and the compiler can see that there's nothing that could throw that checked exception, that's a compile error.



Actually not. You can declare method to throw any Throwable if overrididing is not considered. What you can't do is try/catch checked exception which is not "never thrown" (some method in the try-block must be declared as "throws <thatException>")

Anyways, thanks Matthew and Bert. I didn't notice that line-number thingie, but now I know when code is considered complete and when not
 
Mike Simmons
Master Rancher
Posts: 4280
57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
True, when you write throws "Throwable" or "throws Exception", those are the two special cases where the exception may be checked or unchecked, and so the compiler does not complain if you don't have any code that overtly throws an exception. However for all other checked exceptions (such as, for example, IOException, the one that was relevant here) my statement above is correct. This problem is not about import statements.

You're welcome.
 
Ranch Hand
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mike Simmons wrote: when you write throws "Throwable" or "throws Exception", those are the two special cases where the exception may be checked or unchecked


Mike, here bit clarification would be great. I always consider Throwable and Exception as checked exception since compiler ask programmer to handle when you call them.
 
Matthew Brown
Bartender
Posts: 4568
9
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Seetharaman Venkatasamy wrote:Mike, here bit clarification would be great. I always consider Throwable and Exception as checked exception since compiler ask programmer to handle when you call them.



All checked exceptions are Exceptions and Throwables. But not all Exceptions or Throwables are checked, since RuntimeException is a subclass.

So how it's treated depends on the context. If you declare a method as throwing Exception, the compiler thinks "that might be a checked exception - I'd better force the calling code to handle it". But when the compiler is checking whether a piece of code can throw the exception that is being caught, if it sees Exception, it thinks "any of that code might throw a runtime exception, so I'd better allow it".

In the first case, the fact that the exception might be checked is important, whereas in the second case the fact that it might be unchecked is what matters. As soon as you make it specific, like IOException, then there's no uncertainty.
 
Seetharaman Venkatasamy
Ranch Hand
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Matthew. Compiler is very smart
 
Mike Simmons
Master Rancher
Posts: 4280
57
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Matthew's post. But I want to add some nitpicky clarifications:

Matthew Brown wrote:All checked exceptions are Exceptions and Throwables.


All checked exceptions are Throwables, because all exceptions are Throwables. However "checked exceptions" (in lowercase) would also include any Throwables that are not Exceptions or Errors. (E.g. "throw new Throwable()".) Such things are rare in practice, but perfectly legal, and considered checked exceptions.

Matthew Brown wrote:But not all Exceptions or Throwables are checked, since RuntimeException is a subclass.


Also since Error is a subclass of Throwable.
 
Tapio Niemela
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mike Simmons wrote:True, when you write throws "Throwable" or "throws Exception", those are the two special cases where the exception may be checked or unchecked, and so the compiler does not complain if you don't have any code that overtly throws an exception. However for all other checked exceptions (such as, for example, IOException, the one that was relevant here) my statement above is correct. This problem is not about import statements.

You're welcome.



Sir, I still disagree. The question is all about wrong namespaces; either one should import java.io.IOException or declare the method to throw java.io.IOException

On my previous message by "Throwable" I was referring to Throwable or any it's subclass..

This is perfectly legal:


Code compiles fine, body in the test method never throws exception, still I can declare it to throw *any* Throwable (checked and unchecked) I wish. Note on the testTest that it must catch IOException possible thrown by test-method
 
Mike Simmons
Master Rancher
Posts: 4280
57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh, you're right, silly me - I was mixing up the rules for what you can catch, with what you can put in throws. You can't catch a checked exception (other than special cases Exception and Throwable) unless the compiler finds code that's capable of throwing it. But you can put such exceptions in the throws clause, that's true. Sorry about that - my bad.
 
no wonder he is so sad, he hasn't seen this tiny ad:
the value of filler advertising in 2021
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic