• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Applied Reasoning - wait method

 
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Problem 20
The statement said to be true:
A wait method must be enclosed in try/catch block handling InterruptedException
Do you agree?
If we have the declaration "method throws Exception" then there is no need of try/catch block.
 
Ranch Hand
Posts: 5040
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
well, maybe the intention is to handle the InterruptedException although it is not very clear to
me from the qstn (fragment?) you mentioned. What does the
exam say?
Regds.
- satya
 
rajsim
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is one of the statements in an identify true statements question.
The answer given was true.
There is an absolute word - must - in the statement, hence there is no need to over-interpret the question.
I think the question is OK but the answer given is incorrect.
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Since wait throws InterruptedException, a call to wait should either be enclosed in a try-catch block OR the enclosing method should be declared with a throws clause
So, I guess the must be condition is wrong, and so the answer given is incorrect.
Do you agree?
Ajith
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi

Let me take a blind guess !
The VM knows to handle the error(I mean what sort of error might occur and how 2 handle it) that is thrown by the wait method.
But the VM doesnt know how 2 handle the error(if so) for the methods u created and the exceptions it might throw. Probably it would say "GOD ONLY KNOWS' and thats why it doent even try's it

Regds
Srik
 
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ajith Kallambella:
Since wait throws InterruptedException, a call to wait should [b]either be enclosed in a try-catch block OR the enclosing method should be declared with a throws clause
So, I guess the must be condition is wrong, and so the answer given is incorrect.
Do you agree?
Ajith[/B]


Theoritically this is OK.
But, don't you call wait() to get to some resource that is used in the code right after the wait()? So, isn't it ideal to handle the exception at in a try-catch block right around the wait()? Else, what happens? Control goes back to the caller where the exception could be handled, but I think it is a waste of programming like this. The condition cannot be handled in the caller so that this thread gets the resource anymore.
Am I making any sense, or Am I all confused and jabbering??
Savithri
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Savithri,
You are right too. However, I doubt if you can make such assumptions about practical considerations. If you read the question as is and give NO weightage to "programming habits", I think the must condition goes a little overboard.
In the exam, it is better no to extrapolate the given question, or to interpret its implications beyond the scope of the statement.
Ajith
 
rajsim
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Ajit.
In general, there is no requirement for any statement to
be enclosed in a try/catch block as long as the enclosing
method has a throws clause for the exceptions that might
occur.
If no try/catch block handled the exceptions, JVM will
handle them by terminating the thread and printing the
exception and call-stack on the console.
Agree?
 
Savithri Devaraj
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by rajsim:
I agree with Ajit.
In general, there is no requirement for any statement to
be enclosed in a try/catch block as long as the enclosing
method has a throws clause for the exceptions that might
occur.
If no try/catch block handled the exceptions, JVM will
handle them by terminating the thread and printing the
exception and call-stack on the console.
Agree?


Agreed.
You still have to be careful though. If the code shown was in the (overriding) run() method of Thread Class or the Runnable Interface (which is usually the case), you will get a compiler error if you define them as throwing an InterruptedException. It is because the run() method is not defined as throwing any exceptions.
In this case you have to handle the exception inside the run method itself.
I also remember reading in Exam Cram book that wait() has to have an enclosing try-catch block. I don't have the book with me here, may be some one can verify that.
Savithri
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic