This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Handling InterruptedException in Java
I wonder how InterruptedException should be properly handled. What actions should be performed in catch block? Are there any circumstances when the exception should be delegated to the higher level class?
The point of InterruptedException is to allow a blocking method to cancel early, when requested. The one thing you shouldn't do is nothing; don't just swallow the exception.
If you can't throw the exception from your method, calling Thread.currentThread().interrupt() is usually a good bet.
Check out Brian Goetz's article, http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html, for a good discussion on this topic. Edit: looks like somebody suggested this article already - in any case, it's a good read.
Related
This question already has answers here:
What does java.lang.Thread.interrupt() do?
(10 answers)
Closed 4 years ago.
I know how to interrupt a thread. But I want to know how interrupt method works internally in java multi threading ?
Here's a simplistic answer. If the thread is in a wait condition, an InterruptedException is thrown. If the thread is active, the thread's interrupted flag is set.
This question already has answers here:
Is using Object.wait and Object.notify directly a code smell?
(2 answers)
Closed 7 years ago.
My question is about using wait() and notify() explicitly. Whould we try to avoid it every time we need something like producer-consumer and consider to use BlockingDeque instead.
I tried to think about it and didn't find more or less reasonble explanation. Moreover I tried to invent example where we would have to use wait() and notify() explicitly and failed.
There are better higher level constructs in java.util.concurrent, so using wait/notify nowadays is highly dubious.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
As a team lead which type of exception should I create a base class for in my architecture - checked or unchecked ? My team would start development in a few weeks and I want the architecture to be conducive to them for usage. Any reasons around that would also help.
That depends on the situation.
You use checked exceptions (extend Exception) for things that can go wrong regardless of the input the caller of the method passes. For example, network connections; you can make an HTTP GET request by calling client.get("google.com"); and everything goes well, two minutes later you call once again client.get("google.com"); and then you get an exception because of a network error. As you can see, here you called the same method passing the exact same input "google.com", yet you can get an exception at anytime. Therefore, you must force the caller to catch the exception by making it "checked", so that they handle those cases in which a network error occurs.
You use unchecked exceptions (extend RuntimeException) when the error happens because of some sort of invalid input by the caller of the method. For example, you have the method Integer.parse(String);. The method cannot work properly if you pass a null string here, so you throw an exception if that happens. This case, you should not force the caller to catch it, because the caller is responsible of passing the right input.
Overall: let the them decide, start with a short discussion. Helps people getting to know each-other.
I'd avoid checked exceptions: since they need to be explicitly catched, the catch block could become part of the normal program flow. Increases complexity and thus chance of introducing bugs.
Also don't use custom exceptions when possible, use existing exceptions like IllegalArgumentException. Avoid NullPointerExceptions by never returning null. Furthermore try to use something like bean-validation. That can save a lot of errors in your code caused by invalid (combinations of) arguments. And last but not least, failing fast is better then making your own faulty retry logic.
This question already has answers here:
What is a deadlock?
(19 answers)
Closed 9 years ago.
What is deadlock in programming Object Oriented ?
I had knew deadlock in transaction of Database Systems. But in programming I'm not clear.
I want to know when deadlock occur and how to resolve it.
Thanks!
A deadlock is when you have two or more processes that are each waiting for the other to finish. When this happens, neither one can continue and the program essentially stalls.
There is a basic example here
http://docs.oracle.com/javase/tutorial/essential/concurrency/deadlock.html
well documented.
but, a deadlock occurs when you wait for a object to be freed but that condition is never achieved.
This question already has answers here:
Do spurious wakeups in Java actually happen?
(7 answers)
Closed 8 years ago.
What is the meaning of spurious wakeups in Java? Why they are so dangerous? Can you explain it with an example?
The JVM is allowed to wake a waiting thread without another thread calling its notify() method - a so called "spurious wakeup".
If you don't consider this possibility, you may proceed with processing when the wait state has not been achieved, leading to incorrect behaviour.
The correct approach when woken up is to first check that the state your thread is waiting on has actually been achieved, otherwise return to waiting by immediately calling wait()