When logging in my application, do I hard code my file handler and formatter, or I rely on using the logging.properties file in the JRE? (I have practically finished my code and haven't used logging at all - I'm guessing it might be useful to the exam accessor.)
Brian, when you had an exception, did you show it in a console window or something? Did you have a gui for the server?
Joined: Jan 04, 2007
Depends on the exception. I did the locking and unlocking in the server so the client didn't get SecurityException (trying to update a record locked with a different cookie). Stuff like IOException/RemoteException/RecordNotFoundException were sent to the client and issued to the user (with a JOptionPane)...
I had a small GUI for the Server. When you start the server, it allows you to change the properties (like 'db file location') and start the Server. The Server GUI then quits. To stop the GUI, the user had to Crtl-C.
Just explain it in "choices.txt"...
EDIT: do you mean software exceptions??? (i.e. exceptions from buggy code?). I didn't do anything with them. I said in "choices.txt" that there shouldn't be any software errors so I didn't try to recover from them...anyway, hiding software errors is never a good idea... [ April 26, 2007: Message edited by: Brian Kelly ]
Joined: Oct 16, 2006
Cool, server gui is the same as mine.
What i meant by exceptions is: do you have any catch blocks which call the exception.printStackTrace() method? If yes, that would show up in the console window of the server. However as you stated, and also in my case, the exceptions are sent to the client and they are dealt with on the client side.
Well i guess i should remove printing anything unusual in the server console window and leave everything plain simple.
About the logging : the sun does not mention anything about the log - or log location, so I use the logging with its default settings, if the user want to change it he must provide a new configuration file, of course I document it (in choinces.txt). In this way I avoid any kind of possible IO problems by logging.
Chris, the "exception.printStackTrace()" is a poor technique and it can lead you to a lot of problems. I recommend you to protocol all exception stack traces. By example, in your times most of the people start the application with some mouse clicks on some icons not on the command line in a terminal window - so if this way the "exception.printStackTrace()" are not visible.