File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Servlets and the fly likes Error Handling Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "Error Handling" Watch "Error Handling" New topic
Author

Error Handling

Joao Lopes
Greenhorn

Joined: May 29, 2001
Posts: 7
Using J2EE or Tomcat I have been running a Java program that connects to a remote server and retrives data.
Lots of error trapping is done inside the program. While I was testing the Java code away from the server I used System.exit(1) when I got a error. System.exit will kill the java VM where the program is running.
Until here everything is ok.
Now, after moving to the server I started running the same code and it worked just fine until I got an error.
When an error occurs (like a timeout waiting for a reply from the remote server) a System.exit(1) is executed and I kill the java VM where the program is running AND ALSO THE JAVA VM MACHINE WHERE THE J2EE OR TOMCAT SERVER IS RUNNING.
Not good. Not good at all.
So, what I am looking is for a good and elegant way to send my low level Java errors up to a higher level (JSP page maybe) without destroying the server.
Any, *but any*, help is welcome.
John
[This message has been edited by Joao Lopes (edited June 07, 2001).]
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

Have you thought about throwing a ServletException? Here is a modified snip of code from one of my servlets. the method is called when my cgi parameter is page=SaveItem, and the request and response object are passed in as parameters. The important part is inside the try/catch blocks.This code gives you two examples.

The first is an EJB call. If I can't find the item in question, this is a serious error, so I want the outside world to know about it. When I throw a servlet exception, that's when I get one of those "Error:500 Internal Servlet Error" pages. It also displays the stack trace for me. (both on the 500 error page, and in the console window).

The second is not so serious an error... from my console output, you can see it's probably because the session is already invalidated.. so I can 'bury' this error and not report it back to the user.

[This message has been edited by Mike Curwen (edited June 07, 2001).]
Joao Lopes
Greenhorn

Joined: May 29, 2001
Posts: 7
Dear Mike,
thanks for the code.
I wish it was that simple.
I have to stop the low level Java program to stop running.
Here is a bit from the log it generates:
big giant snip (boy, this is a big log)...
-> dadosSaidaParaParametrosSaida.processarParametroSaida
Parametro de Sa�da: SaldoDia1|2|13,2|0|
-> dadosSaidaParaParametrosSaida.processarCampos
-> tiposSaida.processarComp3
-> tiposSaida.comp3ParaString
<- tiposSaida.comp3ParaString
-> beanHandler.setBean
<- beanHandler.setBean
Nome: SaldoDia1
Parte Inteira e Parte Decimal: 13,2
Valor Ibm: s#?
Valor Iso: 17323901.00
<- tiposSaida.processarComp3
<- dadosSaidaParaParametrosSaida.processarCampos
<- dadosSaidaParaParametrosSaida.processarParametroSaida
big giant snip again.
a "->" means going into a method, while a "<-" means leaving the method.
On the above example we have methods calling other methods. Supose the error occurs after we entered one of the lowest level methods:
-> tiposSaida.comp3ParaString
inside we get an error.
Oh boy, I�m in trouble now. All I want to do after this error is to set something on a bean that stores error numbers and messages (and now for the hard part) leave the Java low level code without killing the Java VM.
Once on the JSP page, I could easly check my error Bean for any errors and in the event of finding one I could show a special page saying blah blah there was an error below and we are in trouble now, you have 10 seconds to leave your chair because your computer will now explode...
The hard part is to leave the low level code.
Thanks.
John

Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

Right, I misunderstood. I didn't realize it was a seperate Java standalone program that gets the errors. This is the program you want to leave, not the servlet.

System.exit(1) can sometimes be like "GoTo End". You can pepper them all over your code, and it's a easy way to write a program. So one option, instead of using System.exit(1), you can re-write those parts of your code, so that they 'naturally' exit the program on an error condition. It would probably involve a lot of if/else if/else blocks.

A second option.. and I haven't really thought this through or tried it... But if you write your program in such a way that one super method, sort of like this:
Then if you don't ever catch any MyBadExceptions, they will eventually cause the program to end abnormally. And in all the times that I've been testing and debugging servlets that end horribly and abnormally with large stack traces, I've never noticed that it's brought down the whole Tomcat instance. Maybe you can do this.

The third option, and I have tried to look this up, but can't find it... (perhaps because it's not possible). Maybe there is a way to specify when you are executing a java program to ensure (with a switch) that the new running instance is in its own JVM.

As another post to the JavaRanch seems to say, each invocation of the 'java' command at a console window should start its own JVM. http://www.javaranch.com/ubb/Forum34/HTML/000621.html
Joao Lopes
Greenhorn

Joined: May 29, 2001
Posts: 7
Originally posted by Mike Curwen:
[B]Right, I misunderstood. I didn't realize it was a seperate Java standalone program that gets the errors. This is the program you want to leave, not the servlet.
I still have to learn the difference between a servelt and a standalone program (this is plain ignorance, nothing else)...

Option One
==========
System.exit(1) can sometimes be like "GoTo End". You can pepper them all over your code, and it's a easy way to write a program. So one option, instead of using System.exit(1), you can re-write those parts of your code, so that they 'naturally' exit the program on an error condition. It would probably involve a lot of if/else if/else blocks.

Right on the money: "a lot" are the key words on the above quote.
If an error occurs I could easly set the error bean.
But then again I would have to leave the method and after leaving it, allready on higher context, I would have to check again if an error occured. Since there was an error I would have to leave for a higher context and so on...
On a large code (and belive me, mine is large) this would mean having to insert hundreds of ifs/elses.
This is actually what I am trying hard to avoid.
Option Two
==========
A second option.. and I haven't really thought this through or tried it... But if you write your program in such a way that one super method, sort of like this:
Then if you don't ever catch any MyBadExceptions, they will eventually cause the program to end abnormally. And in all the times that I've been testing and debugging servlets that end horribly and abnormally with large stack traces, I've never noticed that it's brought down the whole Tomcat instance. Maybe you can do this.
All I can say about this is that I have not tried it.
No doubt the idea is interesting.
Seems like a path to explore. I�ll run some simple tests and post the results here.

Third Option
============
The third option, and I have tried to look this up, but can't find it... (perhaps because it's not possible). Maybe there is a way to specify when you are executing a java program to ensure (with a switch) that the new running instance is in its own JVM.
This is the option I prefer.
If it�s possible it�s the way to go.
The actual code implementation of this is clean and it requires only creating a new bean to store the errors.
I think you are correct when you say that this is not possible but I think it�s worth spending a bit of time making shure things are really like this.

As another post to the JavaRanch seems to say, each invocation of the 'java' command at a console window should start its own JVM. http://www.javaranch.com/ubb/Forum34/HTML/000621.html [/B]

I�ll this URL check this now.
Once again your help has been important.
A big thank you.
John
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

Here is a TS Eliot quote: You'll see why I like this quote - it really, *really* applies to programming. I'll just post one point, and then I'll apologize for calling your programming skills into question.

I am working on a project at work that uses servlets, jsp's, ejb's, simple classes... etc. It's a whole lot of code.

I have a particular servlet that is pretty convoluted. I was never really happy with it. I thought the logic was not as 'clean' as it could be, but I also thought perhaps it had to be convoluted, because that servlet was doing some pretty complex things. (the servlet runs a web based editing tool).

Anyways, in one particular method I had the following type of logic.
Then... my client added a requirement, and I had to revisit this method. A week after I had written this, I was forced to begin to think of how else to do this... and can you *believe* I got all of that... down to this... I was able to realize this kind of 'code cleanup' in 3 other methods!

Now what does all of this mean? Either I really suck at coding efficiently (which I wouldn't dispute).. or "there is (almost) always a better way". And why do I bring it up? It's your one comment.... "On a large code (and belive me, mine is large) this would mean having to insert hundreds of ifs/elses. This is actually what I am trying hard to avoid."

If your code base is completely functional, and there are time limits, and maybe you just *really* don't want to re-write (ie: fix) something that isn't broken... then that is cool. But realize something: There is probably a way to code your class such that it would not require as many if/elses as you think.

So now I'll apologize for implying you can't program efficiently. And you are also correct... using Java's exception throwing and handling ability is probably the best way to 'skip the rest of this program and go directly here...'

Best of luck, whatever you decide.
Joao Lopes
Greenhorn

Joined: May 29, 2001
Posts: 7
You'll see why I like this quote - it really, *really* applies to programming. I'll just post one point, and then I'll apologize for calling your programming skills into question.

I am working on a project at work that uses servlets, jsp's, ejb's, simple classes... etc. It's a whole lot of code.

Aren�t we all?...

I have a particular servlet that is pretty convoluted. I was never really happy with it. I thought the logic was not as 'clean' as it could be, but I also thought perhaps it had to be convoluted, because that servlet was doing some pretty complex things. (the servlet runs a web based editing tool).

Anyways, in one particular method I had the following type of logic.
Then... my client added a requirement, and I had to revisit this method. A week after I had written this, I was forced to begin to think of how else to do this... and can you *believe* I got all of that... down to this... I was able to realize this kind of 'code cleanup' in 3 other methods!

My code needs cleaning!

Now what does all of this mean? Either I really suck at coding efficiently (which I wouldn't dispute).. or "there is (almost) always a better way". And why do I bring it up? It's your one comment.... "On a large code (and belive me, mine is large) this would mean having to insert hundreds of ifs/elses. This is actually what I am trying hard to avoid."

If your code base is completely functional, and there are time limits, and maybe you just *really* don't want to re-write (ie: fix) something that isn't broken... then that is cool. But realize something: There is probably a way to code your class such that it would not require as many if/elses as you think.

I do have some time limits. We all do.
Yes there is allways a different way. And ... it�s done.
You were right.
I took the if/else approach but I got it down to a minimum and it�s working fine.
It did not mess up the original code.
Actually there are advantages for this aproach. I can see (on the log) the exact place where the error took place.
It�s a logic, natural flow, code.
I did try the other sugestions we discussed but I did not get the results I had planned for.
Maybe this is a brute force aproach but it does work well.
There are about 20 different errors being sent to a bean, so it did not imply a great deal of changes on the code.

So now I'll apologize for implying you can't program efficiently. And you are also correct... using Java's exception throwing and handling ability is probably the best way to 'skip the rest of this program and go directly here...'

Hey, you don�t really need to apologise.
I�m quite new to Java but I coded in many other languages in the past.
Coding large programs is allways difficult. When you move along, if you feel that it�s getting out of hand you�re bond to get in trouble latter on.
You know, I�m moving through this with a compass on my left hand and a map on my right hand. Sometimes I have to stop and check the sun�s position. Even like that I have the feeling that I am constantly lost.

Best of luck, whatever you decide.[/b]<HR></BLOCKQUOTE>

I have a new problem with the code. It�s a different problem. I think I should start a new thread, but I�m unsure about the rules.
A quick explanation of the problem: When my code runs it takes a bit of time to run because it has to format messages, use conversion tables, connect via TCP/Ip to a remote server, wait for a reply and unformat back all that stuff. Passing errors to a higher level solved a lot of stuff but... I wish I could block the user on the browser from doing refresh until my code stops running... Seems like doing refresh is causing problems. Is that possible?
Txs.
John

[This message has been edited by Joao Lopes (edited June 12, 2001).]
[This message has been edited by Joao Lopes (edited June 12, 2001).]
 
Consider Paul's rocket mass heater.
 
subject: Error Handling