Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

NX: URLy Bird 1.3.1 Explicit Fatal Exception Handling

 
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bharat, hi Max,
thank you for your responses.
Each time I think I get it with these exceptions, newer questions emerge, I'm sorry.
Slowly I'm starting to believe that myself I'm becoming an Exception
Bharat, you wrote:

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.


Max, you wrote:


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.


Generally, by subclassing the RuntimeException for wrapping the InterruptedException or the IOException, I should make a difference concerning the handling of these two exceptions?
I suppose, yes, the InterruptedException should lead to an exit of the application while the IOException should only lead to a stop of the concrete request ... Unless the application `continues to throw IOExceptions or an IOException causes an InterruptedException during the standalone mode, like you supposed Max (in which case the consequences of the InterruptedException couldn't lead to a corruption of the datas because there isn't any concurrent client)?
If I'm right and the InterruptedException is more drastic than the IOException, I should subclass twice the RuntimeException and give each subclasses an appropriate name?
I hope that my questions aren't too confusing...
Greetings overseas where I suppose it's soon lunch time

Ulrich
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bharat, hi Max,
thank you for your responses.
Each time I think I get it with these exceptions, newer questions emerge, I'm sorry.
Slowly I'm starting to believe that myself I'm becoming an Exception
Bharat, you wrote:

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.


Max, you wrote:


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.


Generally, by subclassing the RuntimeException for wrapping the InterruptedException or the IOException, I should make a difference concerning the handling of these two exceptions?
I suppose, yes, the InterruptedException should lead to an exit of the application while the IOException should only lead to a stop of the concrete request ... Unless the application `continues to throw IOExceptions or an IOException causes an InterruptedException during the standalone mode, like you supposed Max (in which case the consequences of the InterruptedException couldn't lead to a corruption of the datas because there isn't any concurrent client)?
If I'm right and the InterruptedException is more drastic than the IOException, I should subclass twice the RuntimeException and give each subclasses an appropriate name?
I hope that my questions aren't too confusing...
Greetings overseas where I suppose it's soon lunch time

Ulrich
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Max,
I'm sorry, I have reviewed what you have posted in another thread:
NX: Exception handling implementing the DBAccess
and there you suggest to subclass the RecordNotFoundException for the IOException, so I don't want to annoy you with my approach.
I just want to know if the InterruptedException is more drastic than the IOException
Regards,
Ulrich
 
author and jackaroo
Posts: 12199
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ulrich,
I think either one of them could be fatal for your application.
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.
The same sort of logic applies to an IOException. If you get an IOException at file level, what are you going to do? What can you do? You could retry the operation, and possibly it might work, but you don't know what happened, or whether future operations can be relied upon. You don't know if the media is faulty, or if some other application is simultaneously modifying the file or what else is happening. So if you get an IOException, I think the safest thing to do is provide as much information as possible for future investigation, and just exit (as a result of throwing the fatal exception).
Regards, Andrew
 
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's tough question, so I'm not going to answer it . IMO, they should probably both be considered Terrible. Howe Terrible? Terribler enough to cause a shutdown.
M
 
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Andrew/Max,
Gentlemen, looks like both of you missed my question, or worse, chose to ignore me (oh no! Failed even before the assignment submission!). I shall try again! A snippet of my question from above was:


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?


Whould you please clarify?
Thanks again.
Bharat
 
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

AFAIK, the only valid information I could find about thread interruptions are in the java API doc : look at Thread.interrupt(), Thread.isInterrupted() and Thread.interrupted(). It should help to demistify InterruptedException.
Now I can answer the following question :

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?


Sorry, but after 1) , no more line of code will ever execute in your lock method, except the ones you'd put in a finally clause. Let's say that if you don't catch your runtime FatalSystemException somewhere, your server will "shutdown" anyway (by crashing), meaning that your System.exit(1) in the finally clause of lock() would have no real effect. 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.
Best,
Phil.
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Phil,
You wrote:


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.


Thanks Phil, that is what I am doing. I will leave it alone.
Regards.
Bharat
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andrew, Max, Bharat, Phil,
now, I got it. Thank you for your patience
Ulrich
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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 :


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.



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.


Bharat,
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. Isn't RMI great?
All best,
M
[ September 16, 2003: Message edited by: Max Habibi ]
[ September 16, 2003: Message edited by: Max Habibi ]
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Max,

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.


Mmh here is what you wrote exactly, Max :

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.


And ClosedByInteruptException is this :

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.


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.
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
/*

Originally posted by Philippe Maquet:
[QB]Hi Max,
The problem is not that I am a cowboy, but a slow one ; :


well, so long as you're not a cowgirl


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.


Philippe, I'm having some trouble following this. Can you please restate your question? If you're asking about what will happen if you do such and such, I suggest you spend 45 minutes playing around with the code


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.


Ok, that's your prerogative. I disagree. IMO, a Thread is interrupted in our application, then something very, very bad has happened that is compromising the state of the entire application. My suggestion is to shut down. You are, of course, free to disregard it


BTW, there is no other possible cause for a thread to get interrupted than a call to its interrupt() method, AFAIK.


This is probably a Java experience issue. Back in the dark ages, when a Thread was working on IO and it caught an IOException, it wouldn't cause an InteruptedException. So while the Thread couldn't do IO, it was still blocking, sometimes even keeping the resource. Or worse, when a Thread was interrupted, it wouldn't always close it's IO connection. This sort of thing was a nightmare to work with. Hence, the improvements I was trying to point you to in NIO. You're free to explore them or not, as it suits your mood.


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.


In this application, if there's ever an InterupttedException, then the KISS principle tells us to shut down, IMO. Also, it's worthwhile for you to be aware that IOExceptions can occur randomly (if rarely). 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. For example, say someone just manually deletes the file you're working with.
All best,
M
[ September 16, 2003: Message edited by: Max Habibi ]
 
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Phil,
Max

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.


I agree with Max 100%. The only difference I would throw either IOException (As Max did in his book!) or a RuntimeException.
Best,
Vlad
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But that's the beauty of ClosedByInteruptException. It is a IOException
M
 
Ranch Hand
Posts: 435
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry to labour this point, but I wrongly thought Interupted Exception was an impossible exception unless you were doing something wrong. I now know better.
I've been wondering what to do with my Interrupted Exception, I currentlly wrap it in a RecordNotFoundException and tunnel it through my the interface SUN kindely provided me. I thought throwing a Runtime Exception was a big no no as it's not really a programing/system type error.
So when can you throw a Runtime exceptions. This thread seems to imply that it's ok to generate a run-time exception from a checked exception.
Tony
[ September 16, 2003: Message edited by: Tony Collins ]
 
Max Habibi
town drunk
( and author)
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So long as your system is crashing immediately anyway, I think you're ok. Remember, you're not really 'throwing' a runtime exception here. You're catching a InteruptedException, and executing System.exit.
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.
Make sense?
M
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Max,
You wrote:


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)?
2. 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. I will and post my findings tomorrow. One question that I have here is that "other" types of catastrophic events, e.g., somebody pulled the plug on the server!, can also cause an RMI exception to be communicated back to the calling client. How do you distinguish between the two? Are you saying that we should design a "blanket" TerribleException to be thrown for [B] any [/ B] possible RMI exception or just a particular execption? 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. Catch it, rethrow a FatalSystemException which is chained to the "root" cause, let it bubble-up to the client. Client catches it in appropriate place, tests whether it is an instance of InterruptedException, tailors an appropriate user message, displays it in a dialog-box, and executes a System.exit(1). Let the server run, there is no need to explicitly shut-down the server. Other clients will get the same message if it is a persistent problem. If it isn't, then life goes on. Even if every client gets the same message, no harm done.
What do you think?
Regards.
Bharat
 
Andrew Monkhouse
author and jackaroo
Posts: 12199
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Max,

Philippe The problem is not that I am a cowboy
Max well, so long as you're not a cowgirl


Ooooh - I should tell Kathy you have a thing against cowgirls
Regards, Andrew
 
Andrew Monkhouse
author and jackaroo
Posts: 12199
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bharat,

This implies that the code-base should be different for the network mode and standalone modes. Does it?


Not necessarily. There is going to be a point of convergence between a local connection and a remote connection. At that point, you should be abstracting the connection type.
So at that abstraction point
  • if you are in networked mode and you get the RemoteException telling you that the server aint there no more, you throw a TerribleException
  • if you are in local mode and you get the InterruptedException (or whatever other exception we are declaring as fatal exceptions) then you throw a TerribleException.


  • Either way your higher levels are just responding to the TerribleException and informing the user before shutting down.
    (Who came up with the name "TerribleException" anyway? :roll: )
    Regards, Andrew
     
    Andrew Monkhouse
    author and jackaroo
    Posts: 12199
    280
    Mac IntelliJ IDE Firefox Browser Oracle C++ Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Bharat,
    Sorry, I only answered one of your two questions.

    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.


    Excellent idea!

    "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?


    Why do you want to?

    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.


    How do you know that no harm is being done?
    Lets say that the original exception was thrown because the JVM detected some other application accessing the database simultaneously (I don't even know if this is possible, but I am just giving an example). Lets further assume that this other application has cached the records and only intends to update them all at the end of whatever job it is doing.
    So we ignore that error, and keep processing. Over the next hour we process hundreds of transactions worth thousands of dollars. And then that other process decides to do it's update, and just overwrites all those transactions.
    -----
    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. Shut down and let a human come along and determine what went wrong.
    Regards, Andrew
     
    Max Habibi
    town drunk
    ( and author)
    Posts: 4118
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Originally posted by Andrew Monkhouse:
    Hi Max,

    Ooooh - I should tell Kathy you have a thing against cowgirls
    Regards, Andrew


    Actually, the problem is that I have a thing for cowgirls. Why do you think I'm always chatting up Kathy?

    On a more serious note: I agree with Andrew here.
    M
    [ September 17, 2003: Message edited by: Max Habibi ]
     
    Bharat Ruparel
    Ranch Hand
    Posts: 493
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hello Andrew,
    I followed-up on the idea of executing System.exit(1) in the data server class. I used MagicCookieException instead of the InterruptedException, but the concept is the same. When the remote client tries to instantiate a Data object the magic cookie is deliberately set to a wrong value. I get the following exception:

    What exception do I trap on the client side to show to the user and how do I determine the root-cause exception?
    Regards.
    Bharat
     
    Andrew Monkhouse
    author and jackaroo
    Posts: 12199
    280
    Mac IntelliJ IDE Firefox Browser Oracle C++ Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Bharat,
    Could you please post the code that logged that message? It looks like you are not logging the name of the exception you should be catching.
    Either that, or you should be catching java.rmi.UnmarshallException (doesn't sound right to me, but I guess it could be). 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".
    Regards, Andrew
     
    Bharat Ruparel
    Ranch Hand
    Posts: 493
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hello Andrew,
    Here is the piece of code that caused this stack trace:

    You can see how I created this condition. My magic cookie value is 257. I deliberately changed it to 300. I do a System.exit(1) here to shut the server down which it does, but then how do I trap what you are saying at the client-side?
    You go on to say that:


    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".


    If you see that stack trace that I gave you, it does show:
    Caused by: java.net.SocketException: Connection reset.
    Here is the MainWindow class constructor that instantiates the connection:

    When I run the code I do see a dialog-box from: GUIHelper.handleException("Failed to open network connection"); followed by the stack-trace which I posted in my last post.
    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 as in the following code?

    Regards.
    Bharat
     
    Andrew Monkhouse
    author and jackaroo
    Posts: 12199
    280
    Mac IntelliJ IDE Firefox Browser Oracle C++ Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Bharat,
    Sorry, I wanted to see the code that you had that was logging the exception. The bit of code that generated the output starting "Sep 18, 2003 3:14:13 PM suncertify.gui.GUIController ...."
    And the only reason I wanted to see that was so that I could see whether that code was actually obscuring which exception was thrown.

    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 [...]?


    I think we are getting ahead of ourselves here.
    I really want to know what the exception is that caused that log message from your earlier post.
    If that exception is one of your exceptions (TerribleException, ReallyBadException, NotNiceException .... ) then you might want to get to it's cause so that you can give the user a more useful message (e.g. "Network connection to server application lost" rather than "Crashing now").
    However if the exception is already one of the Sun exceptions, then it may already provide you with a reasonable message that you can provide to the client, in which case you will not need to get to the root cause.
    Regards, Andrew
     
    Bharat Ruparel
    Ranch Hand
    Posts: 493
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hello Andrew,
    The following code generated the output:
    "Sep 18, 2003 3:14:13 PM suncertify.gui.GUIController ...."

    This is the constructor of my MainWindow which takes a string argument. When I run my client with no flag, "networkConnection" is passed as a parameter. Therefore, the specific bit of code that causes that message that you asked to be displayed is:

    I know that this is where the GUIControllerException is thrown because I see the message "Failed to open network connection" in my dialog box shown by calling GUIHelper.handleException("Failed to open network connection.").
    The GUIControllerException class is as follows:

    Is that what you were asking me to post?
    By the way, I am having a terrible time creating the dialog box that is extended from JDialogBox in the following post.
    NX: URLy Bird 1.3.1 Suncertify.properties
    https://coderanch.com/t/184161/java-developer-SCJD/certification/NX-URLy-Bird-Suncertify-properties
    Thanks and regards.
    Bharat
     
    Ulrich Heeger
    Ranch Hand
    Posts: 266
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Bharat,
    I have just a question concerning the message you got:

    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


    Do you log explicitly this message with logging or is this message due to a System.exit(1)-command in your GUIHelper?
    Greetings
    Ulrich
     
    Bharat Ruparel
    Ranch Hand
    Posts: 493
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hello Ulrich,
    This message is due to the System.exit(1) command in the constructor of my Data class which checks for the desired Magic Cookie value. If the cookie does not match, a System.exit(1) is executed which is meant to shut-down the server as Andrew and Max are suggesting.
    The GUI System.exit(1) is executed much further up in the MainWindow class of my GUI. I was merely experimenting with what was being suggested in this thread. The GUI handler indeed does the right exception handling, I may decide to stick with it as Phil is suggesting.
    Regards.
    Bharat
     
    Ulrich Heeger
    Ranch Hand
    Posts: 266
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Hi Bharat,
    I was just asking because I didn't see the problem about which you and Andrew were debating.
    You wrote above:

    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)?


    I think you're right. Because there will be a RemoteException between InterruptedException and GUIException. But if you catch your the InterruptedException(i.e. RuntimeException) at the Middletier, get the cause and transmit with throw new Remoteexception.initCause(InterruptedException) then we would have the same state for the networking mode or the standalone mode. Or I am missing the point of the discussion?
    Greetings
    Ulrich
     
    Legend has it that if you rub the right tiny ad, a genie comes out.
    Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
      Bookmark Topic Watch Topic
    • New Topic