Forums Register Login

NX: concerning threads & exceptions

+Pie Number of slices to send: Send
Hi everyone,
I have just two questions concerning threads:
I have read somewhere to ensure that an action will be executed within the event-dispatching thread is to include it within:

I don't know if this is necessary, but otherwise I'm afraid of a freezed GUI if I don�t ensure the integrity of the event-dispatching thread
In my Server-Class I have implemented a second thread within it's run-method its written (I have to admit I have copied Max' idea :

the refresh-method of Data looks like:

So I notify my WeakHashMap to ensure that no record lockec by a dead client lets another waiting client starve.
Now my question:
Is this ok to catch the InterruptedException and not to throw it further to the client?
Because the InterruptedException which may occur for the lockRecord I wrapped it in a RuntimeException which will be thrown to the client.
Comments?
Thanks in advance & greetings
Ulrich
+Pie Number of slices to send: Send
Hi Ulrich,

So I notify my WeakHashMap to ensure that no record lockec by a dead client lets another waiting client starve.


Nice !

Is this ok to catch the InterruptedException and not to throw it further to the client?


Yes IMO. From a Thread.run() method you cannot pass an exception to any caller anyway, except through a RuntimeException by ... making your application crash, wich is not your goal I presume . Also, your thread will never be interrupted "by magic", meaning that if you don't interrupt it somewhere in your code, InterruptedException will never been thrown/catched. But you could document it within the catch block, and better catch InterruptedException rather the generic Exception.
Just a question : did you make that thread a daemon thread ?
And may I a comment on the code you posted above ? As sleep() is a static method, Thread.sleep(50000) is nicer to read (and probably more efficient) than Thread.currentThread().sleep(50000).
Best regards,
Phil.
+Pie Number of slices to send: Send
Hi Phil,
thank you for your reply.

From a Thread.run() method you cannot pass an exception to any caller anyway, except through a RuntimeException by ... making your application crash, wich is not your goal I presume . Also, your thread will never be interrupted "by magic", meaning that if you don't interrupt it somewhere in your code, InterruptedException will never been thrown/catched. But you could document it within the catch block, and better catch InterruptedException rather the generic Exception.




Just a question : did you make that thread a daemon thread ?


Mhm, good question, I haven't thought about that. Until now I haven't made it a daemon thread, do you think that's necessary?
Because the server can only be stopped by applying the Exit-button of my Server-GUI which will cause a System.exit(1). So the thread above will be stopped also. Or have I missed something?
Greetings to Brussels
Ulrich
+Pie Number of slices to send: Send
Hi Ulrich,
I think you're right in this thread. Anyway, I stand corrected.
If a RuntimeException is thrown from some thread, it *will not* make your application die, but only the thread concerned by the exception.
The language specs (section 11.3) make that very clear : "If no catch clause handling an exception can be found, then the current thread (the thread that encountered the exception) is terminated".
And I just wrote a small test which proves it.
So, *if* you want your application to stop in that case (could be reasonable if you feel that the job performed by that thread is important for the global behaviour of your app), you could add some catch (RuntimeException re) block and call System.exit from it.
Now I still believe that catching all exceptions (including runtime ones), as you did above, and simply "continue" the loop is not good practice.
Any comment, Max ?
Best regards,
Phil.
+Pie Number of slices to send: Send
Hi Phil,
thanks for your comments.
I have to admit that I don't know if in the situation above there might be a possibility of other RuntimeException than IllegalArgumentException:

Because in the Javadocs for notifyAll() and sleep(int ...) there aren't any RuntimeExceptions other than IllegalArg.Ex., I don't know if that means that no further RuntimeException might occur? Is there generally the possibility of RuntimeException we might not anticipate?
If you permit, I might ask two more questions concerning RuntimeExceptions:
1.Concerning the old question of wrapping IOException and InterruptedException within the Data-Class. Is it recommendable to declare them in the method signatures to clarify the wrapping solution?
2.In this thread there was a short discussion if MagicCookieException should be a RuntimeException or not.
Vlad wrote:

E.g. an invalid Magic cookie is not an implementation error, so it should be a checked exception.


Have I missed something, is a RuntimeException an implementation error?
Thanks & Regards
Ulrich
+Pie Number of slices to send: Send
Hi Ulrich,
For your question 1., I don't think so. Wrapped exceptions are not declared, neither in the throws clause of the method signature, nor with a @throws javadoc declaration. Now you still may document that wrapping itself in the method javadoc comment, or even *in* the @throws javadoc clause for the "master" exception, I think.
For the rest, I think the article Frankie posted in this other thread could help you.
Regards,
Phil.
+Pie Number of slices to send: Send
Hi Phil,
thanks for your help
Ulrich
+Pie Number of slices to send: Send
Hi Phil,
sorry to annoy you once more but after reading this article there is still my first question open: Concerning the RuntimeExceptions which might occur while calling the methods Thread.sleep(...) and notifyAll().
I can articulate my question in a different way:
Does Sun document in Javadoc within the @throws tag all unchecked exceptions or might it be possible that another RuntimeException than IllegalArgumentException might occur?
Thanks in advance & Greetings
Ulrich
+Pie Number of slices to send: Send
Hi Ulrich,
From what I read in the javadoc tool doc (Documenting Exceptions with @throws Tag), you may expect other RuntimeExceptions than the ones documented.
Here is an excerpt from the link above :


Guidelines - Which Exceptions to Document
Document the following exceptions with the @throws tag:
All checked exceptions.
(These must be declared in the throws clause.)
Those unchecked exceptions that the caller might reasonably want to catch.
(It is considered poor programming practice to include unchecked exceptions in the throws clause.)
Documenting these in the @throws tag is up to the judgment of the API designer, as described below.


Best,
Phil.
+Pie Number of slices to send: Send
Hi Phil,
thank you very much. Perhaps see you soon at la Grande Place
I'm really thinking about to move to Brussels when my job contract expires.
Greetings
Ulrich
+Pie Number of slices to send: Send
Hi Ulrich !

I'm really thinking about to move to Brussels when my job contract expires.


Great ! If you move, see you soon for sure then !
And if you don't, there is still Carnaval...
Best regards,
Phil.
+Pie Number of slices to send: Send
Hi Phil,

Best,
Ulrich
I child proofed my house but they still get in. Distract them with this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 929 times.
Similar Threads
Not Clear about Interrupt
ThreadGroup
where to start threads
NX: concerning the event-dispatching thread
NX: Server GUI
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
Comments on lock/unlock please
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 28, 2024 05:33:56.