aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: IO- and InterruptedException. Please Help!!! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX: IO- and InterruptedException. Please Help!!!" Watch "NX: IO- and InterruptedException. Please Help!!!" New topic
Author

NX: IO- and InterruptedException. Please Help!!!

Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi everyone,
I would be very thankful if somebody could help me
I'm referring to this thread:
Andrew and Max suggested that when an IOException or InterruptedException occured within the methods predefined by DBAccess to throw a wrapping RuntimeException and exit. But how do you alert the user that the application will exit
In standalone mode you could exit at the client side like:

But in the remote mode?
With the code snippet above you would only provocate an exit at the client's side, but not a server shut down.
Another alternative would be to implement the application exit at the server side, within Data Class, like:

without throwing a FatalSystemException. The advantage of this solution would be that each remote client would get a RemoteException like Max wrote:

Andrew is right here, as usual. If either an IOException or Interrupted Thread Exception does happen, you're ok to just force a server crash. Your middle tier(or GUI, depending on your design) should in turn catch the RMI exception that accompanies a system crash, and in turn throw it's own TerribleException. The TerribleException is a BusinessException that you yourself created, and it chains the offending RMI exception.
The GUI displays a friendly message to the user informing them of the system crash, and logs the error. So, to wit, your System.exit(-1) on the server side has the effect of doing two things. It stops the server, and it (indirectly) causes an RMI exception to be thrown to all of the GUI clients, not just the one who made the call.

The disadvantage consists in the fact that in the standalone mode, the user won't get any information that the application will exit.
At some other place in this thread, Max wrote:

If the server goes, the client will get a RMI connection exception, which they can, in turn, treat as a TerribleException, etc.
Or, you could throw a TerribleException and start a Thread to shut down the server. Either works, though the latter can be messier.

I think the idea with a new thread can solve the problem by insisting throwin an unchecked exception, like this code snippet within the Data-Class demonstrates:

How have you handled this issue or do I complicate the problem?
Greetings
Ulrich
[ January 21, 2004: Message edited by: Ulrich Heeger ]
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi,
can somebody help me, please ...
Ulrich
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Ulrich,
Network mode :
------------


Standalone mode :
---------------


It's just a "big picture", to be adapted according to your implementation. But does it make sense ?
Best regards,
Phil.
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi Phil,
thank you for your reply.
It's just a "big picture", to be adapted according to your implementation. But does it make sense ?

that's the point.
I have three alternatives:
1. just throw a FatalSystemException without system.exit()
advantage: I don't have to care about a potential server shut down and to let the user decides if he wants to contact the Systemadmin to have a look on it.
disadvantage: like Andrew wrote:

My view is that something has happened that should not be possible to have happen, and we therefore no longer know whether we are in a valid state to continue processing.
We don't know if the user decides to inform the Systemadmin when this one will arrive and so on.
2. just system.exit() without throwing a FatalSystemException.
advantage: simple and effective the remote client will get a RemoteException and thus could make an application closing
disadvantage: in the standalone mode, the user doesn't get any message, in the network mode, the user only gets a remoteException without being informed that the server has arbitrarly been shut down due to an IO or InterruptedException.
3. the above solution
advantage: avoiding the danger of further transactions to a corrupted system. an appropriate message can be sent to the user.
disadvantage: The implementation solution with a second thread doesn't really satisfy me and like Max says can be messier. But I don't see another implementation solution?!
Comments?
Another question: Do you think it's recommendable to transform the exceptions of the Data Layer at the Business Layer in new exceptions or do you think it's ok to delegate these exceptions further to the GUI-Level and there to wrap them in a GUIException? (I have the 2-tier approach)
I'm really very happy about your help,
thanks a lot,
Ulrich
(PS: I will probably be in Brussels in the beginning of February, hope to see you there)
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Ulrich,
I have a class early in the morning tomorrow, so I cannot go further with this tonight. But I'll come back to this thread tomorrow night, promised !
Best,
Phil.
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Ulrich,
Sorry, but some unexpected event made that I couldn't post anything on JR last night.
I didn't see Max's comment about solution 3, but it would be far less messy if you coded and used some throwExceptionAndExit(RuntimeException re) method (in some suncertify.util package). In such a catch(IOException e) block, a single line of code would then do the job.
If it works (I guess you tested it carefully), why not ?
Best,
Phil.
PS: It will be nice to see you soon !
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi Phil,
thanks a lot for your help.
It's really amazing, you take so much elaboretness to follow other's argumentation here in this forum (you seem to be everywhere ) and your comments are always helpfull.
Vive la grande Place
Ulrich
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi Phil,
sorry to bother you once more but I have still questions open.
Thanks for your proposition with the throwExceptionAndExit(RuntimeException re)-method. Good idea.
But now I'm asking myself if I should only use this method for IOExceptions or also for InterruptedException.
Because when an IOException can occur without having been caused by an implementation error.
The InterruptedException whereas is an implementation error?!
So, if I provoke a System.exit for an exception due to an implementation error, I should for reasons of consistence also handle similarly the other Exceptions caused by an bad implementation, like SecurityException (if I assume that the caller has strictly to follow the chronology (lock record, change record, unlock record).
On the other hand, InterruptedException contrarly to SecurityException, will be wrapped in a own subclass of RuntimeException and at this point, being so far, I can also provoke a System.exit.
But for the SecurityException for example, within the unlock-method, I could also make following call:

I don't like the idea of provoking a System.exit() for Exceptions due to an implementation error because these problems should be solved during the developping period.
What would you suggest?
Greetings
Ulrich
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Hi Ulrich,
Thanks for your kind comments.
But now I'm asking myself if I should only use this method for IOExceptions or also for InterruptedException.
Because when an IOException can occur without having been caused by an implementation error.
The InterruptedException whereas is an implementation error?!

What both exceptions have in common is that you consider/decide that they are *not recoverable* at the server level. So handling both exceptions the same way makes sense IMO.
So, if I provoke a System.exit for an exception due to an implementation error, I should for reasons of consistence also handle similarly the other Exceptions caused by an bad implementation, like SecurityException (if I assume that the caller has strictly to follow the chronology (lock record, change record, unlock record).

You would be right in a 3-tiers implementation where Data is not exposed to clients (though the System.exit() would be performed from the business tier, not from Data). But in a 2-tiers one, the implementation mistake in this case is client side, so there is no reason to shutdown the server at all. Think of the fact that your server may serve multiple client types at the same time (Web application / standard application). If one of them is buggy but the other one behaves well, it would be a shame to stop the server, right ? Another argument is that SecurityException is there to *protect* the server and inform clients of their wrong behaviour. But would a fatal protection still be a protection ?
Regards,
Phil.
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi Phil,
What both exceptions have in common is that you consider/decide that they are *not recoverable* at the server level. So handling both exceptions the same way makes sense IMO.

You would be right in a 3-tiers implementation where Data is not exposed to clients (though the System.exit() would be performed from the business tier, not from Data). But in a 2-tiers one, the implementation mistake in this case is client side, so there is no reason to shutdown the server at all. Think of the fact that your server may serve multiple client types at the same time (Web application / standard application). If one of them is buggy but the other one behaves well, it would be a shame to stop the server, right ? Another argument is that SecurityException is there to *protect* the server and inform clients of their wrong behaviour. But would a fatal protection still be a protection ?

Thanks for this convicing argumentation.
Greetings
Ulrich
PS. I will be in Brussels from 13. to 15. February, hope to see you to drink some beers, more beers or even much beers
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
PS. I will be in Brussels from 13. to 15. February, hope to see you to drink some beers, more beers or even much beers

You're welcome!
Phil.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NX: IO- and InterruptedException. Please Help!!!