I thought that whole motivating force for starting this thread was dealing with situations where "things" happen that are "drastic" in nature. Hence the name "FatalSystemException" in the first place! Under normal circustances, in the standalone mode, this should never happen. For that matter, if your code is right and you have designed your system so that each client has one instance of the Data class (my locking strategy is based on that premise), you still should never get that exception. The way I understand it (and I may be wrong!), whenever you sub-class the RuntimeException class, you are implicitly acknowledging that these "types" of exceptions are rather "drastic" and "unusual" but should they occur anyway, here is how you have chosen to deal with them.
I would think yes. For example, if you're not using a cache, then an IO exception will cause an InterruptedException, I think. Frankly, I would react the same way. Have the lock/unlock catch the InterruptedException, wrap it in some other RuntimeException(say, ReallyBaDThingHappendedException), and throw it to the client. The client can catch that and go from there.
I thought that whole motivating force for starting this thread was dealing with situations where "things" happen that are "drastic" in nature. Hence the name "FatalSystemException" in the first place! Under normal circustances, in the standalone mode, this should never happen. For that matter, if your code is right and you have designed your system so that each client has one instance of the Data class (my locking strategy is based on that premise), you still should never get that exception. The way I understand it (and I may be wrong!), whenever you sub-class the RuntimeException class, you are implicitly acknowledging that these "types" of exceptions are rather "drastic" and "unusual" but should they occur anyway, here is how you have chosen to deal with them.
I would think yes. For example, if you're not using a cache, then an IO exception will cause an InterruptedException, I think. Frankly, I would react the same way. Have the lock/unlock catch the InterruptedException, wrap it in some other RuntimeException(say, ReallyBaDThingHappendedException), and throw it to the client. The client can catch that and go from there.
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
I am a bit mystified about shutting down the server. Do you mean to say when you catch the InterruptedException in the lock method of the Data class, do the following:
1. Wrap it into a sub-class of RuntimeException, e.g., FatalSystemException and throw it as a chained exception. AND RIGHT AFTER THAT;
2. Issue a System.exit(1) in the lock method of the Data file to shut the "Server" down?
SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
I am a bit mystified about shutting down the server. Do you mean to say when you catch the InterruptedException in the lock method of the Data class, do the following:
1. Wrap it into a sub-class of RuntimeException, e.g., FatalSystemException and throw it as a chained exception. AND RIGHT AFTER THAT;
2. Issue a System.exit(1) in the lock method of the Data file to shut the "Server" down?
Now if you decide to catch it, analyze the cause and decide what to do depending on the latter, it's far better that you don't System.exit(1) from lock() to let such higher level decision a chance to be made.
SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
Originally posted by Philippe Maquet:
Hi Bharat,
Unfortunately, I cannot be of much help as far InterruptedException is concerned, because I have a quite different thought about what it is and how it should be handled. I had a long discussion with Vlad in that field in another thread and we couldn't agree.
And I cannot agree with (or simply understand) neither what Max writes :
Max: (about a lock() method)
For example, if you're not using a cache, then an IO exception will cause an InterruptedException, I think.
nor what Andrew writes about it :
Andrew:
Our basic premise with InterruptedException is that it should never happen. If it does happen, then we don't know how it happened or what to do, so we are going to throw a fatal exception and exit.
Whoa cowboy, slow down: Andrew is right, and so am I . Assuming you're using NIO(and this is a great reason for doing so), The read and write method throw a special IOException(when Interrupted) that sets the Interrupt flag. Look into ClosedByInteruptException and Writeable(and Readable)ByteChannels.
For example, if you're not using a cache, then an IO exception will cause an InterruptedException, I think. Frankly, I would react the same way. Have the lock/unlock catch the InterruptedException, wrap it in some other RuntimeException(say, ReallyBaDThingHappendedException), and throw it to the client.
Checked exception received by a thread when another thread interrupts it while it is blocked in an I/O operation upon a channel. Before this exception is thrown the channel will have been closed and the interrupt status of the previously-blocked thread will have been set.
Originally posted by Philippe Maquet:
[QB]Hi Max,
The problem is not that I am a cowboy, but a slow one ; :
on which thread your interrupted flag will be set ? The one which is waiting in lock() to be notified by some unlock() ?... the same thread probably which, while waiting in lock() was also blocked in an I/O NIO operation in some other method ?
A kind of thread which I don't know yet, able to block at the same time in multiple methods...
![]()
That should be explained IMO.
Now, and generally speaking, I disagree with the fact that InterruptedException must be seen as (and translated into) some sort of "FatalException". Thread.interrupt() is a way to signal to a thread that it's interrupted. Period.
BTW, there is no other possible cause for a thread to get interrupted than a call to its interrupt() method, AFAIK.
If the interrupted thread was blocking, it gets an InterruptedException, With this side effect that its interrupted status is cleared. Now, depending on the context, you may decide what is the best thing to do with it, keeping in mind that the guy who would have code an interrupt() call somewhere, probably had another aim than crashing your nice application.
Best,
Phil.
If you have a thread that's in the middle of doing something with that IO resource, then you want your InteruptedException to be thrown.
RMI will be throwing the RMI Connection exception on your behalf, and your GUI clients will receive that. When they do, they throw their own TerribleException, so that the Business tier can communicate the error to the GUI layer. The GUI lay in turn logs the exception, displays a "Something terrible has happened" message, and executes it's own System.exit.
SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
Philippe The problem is not that I am a cowboy
Max well, so long as you're not a cowgirl![]()
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
This implies that the code-base should be different for the network mode and standalone modes. Does it?
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
In the network mode, RMI will signal to the client that it cannot find the connection. What type of exception will it throw? May be I should try it myself and see.
"other" types of catastrophic events, [...] can also cause an RMI exception to be communicated back to the calling client. How do you distinguish between the two?
In my humble opinion, there is no need to execute a System.exit(1) in the catch block of the lock method which catches the Interrupted exception.[...] Let the server run, there is no need to explicitly shut-down the server. [...] Even if every client gets the same message, no harm done.
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Originally posted by Andrew Monkhouse:
Hi Max,
Ooooh - I should tell Kathy you have a thing against cowgirls![]()
Regards, Andrew
SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
If you get the cause of the exception you catch, you will find that it is a java.net.SocketException and the SocketException's message is "Connection reset".
SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
Are you saying that I extract the root cause in the case of a "networkConnection" since this is a network connection and compare it to java.net.SocketException [...]?
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
Sep 18, 2003 3:14:13 PM suncertify.gui.GUIController setConnectionTypeSEVERE: Error unmarshaling return header; nested exception is: java.net.SocketException: Connection resetjava.rmi.UnmarshalException: Error unmarshaling return header; nested exception is: java.net.SocketException: Connection resetat sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:203)at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)at suncertify.remote.ConnectionFactoryImpl_Stub.create(Unknown Source)at suncertify.remote.RoomConnector.getRemote(RoomConnector.java:42)at suncertify.gui.GUIController.setConnectionType(GUIController.java:142)at suncertify.gui.GUIController.<init>(GUIController.java:68)at suncertify.gui.MainWindow.<init>(MainWindow.java:106)at suncertify.gui.GUIRunner.<init>(GUIRunner.java:50)at suncertify.startup.ApplicationRunner.main(ApplicationRunner.java:24)Caused by: java.net.SocketException: Connection resetat java.net.SocketInputStream.read(SocketInputStream.java:168)at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)at java.io.BufferedInputStream.read(BufferedInputStream.java:201)at java.io.DataInputStream.readByte(DataInputStream.java:276)at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:189)... 8 moreProcess terminated with exit code 1
SCJP,SCJD,SCWCD,SCBCD,SCDJWS,SCEA
Hello Max,
You wrote:
quote:
--------------------------------------------------------------------------------
RMI will be throwing the RMI Connection exception on your behalf, and your GUI clients will receive that. When they do, they throw their own TerribleException, so that the Business tier can communicate the error to the GUI layer. The GUI lay in turn logs the exception, displays a "Something terrible has happened" message, and executes it's own System.exit.
--------------------------------------------------------------------------------
Few follow-up questions:
1. This implies that the code-base should be different for the network mode and standalone modes. Does it? Or your implied assumption (assertion?) here is that "there can never be an Interrupted exception in the standaone mode." Therefore this particular exception handling only comes into play possibly for the network (a remote possibility at that)?
You ridiculous clown, did you think you could get away with it? This is my favorite tiny ad!
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
|