A bit confused on my choice of a Database Eception...

[Yucca Nel]

I did some research on how I could throw a good exception in my program and I was thrown a bit off by the following...

I see some people go the route of making a database exception and then using it to throw a IOException and a EOFExcption as a cause as follows...

 } catch (FileNotFoundException fne) {
				throw new DatabaseException(
					ApplicationConstants.FILE_NOT_FOUND, fne);
			} catch (EOFException eof) {
				throw new DatabaseException(ApplicationConstants.EOF_ERROR, eof);
			} catch (IOException ioe) {   

My question is this... why rethrow an exception you caught that already has meaning (IOException) through an instance of another exception?

Here is what I planned to do....

1) Have parent DatabaseException for all database related Exception.
2) 1 subclass DatabaseException > InvalidDatabaseException (gets thrown when the magic it is determined to be an incorrect database).
3) 1 subclass DatabaseException > RecordNoExists exception (gets thrown when the record already exists)

and possibly some others but the main point is I wanted my DatabaseException to ony be used for database reated exceptions yet I see
some people create instance of DatabaseExceptions for IOException. Surely doing the following is sufficiant.... (My current code).

  if(magicCookie != Contractor.MAGIC_COOKIE){
                    throw new InvalidDatabaseException("The database supplied" +
                            "is not the correct one for this program");
                }
            }
            catch(FileNotFoundException fnf){
                System.out.println(fnf);
                fnf.printStackTrace();
            }
            catch(EOFException eof){
                System.out.println(eof);
                eof.printStackTrace();
            }
            catch(IOException ioe){
                System.out.println(ioe);
                ioe.printStackTrace();
            }  

Is printing a stack trace not good enough for an IOException for the SCJD exam? I feel like my DatabaseException is much cleaner and so is the subclass I created because it is only being used for InvalidDatabase exceptional condition.

[Alecsandru Cocarla]

Why do you think that printing out the exception is enough for an IOException? What if your server somehow throws dozens of such exceptions, corrupting your entire database? How much would it help having all the stacktraces printed to some volatile console output?

[Roel De Nijs]

Hi Yucca,

1. I don't think your current code is sufficient: e.g. if a user selects a file (in your gui) and it appears to be a none existing file and you just print the stacktrace to sysout, how will you be able to tell the user he has selected a wrong file?
2. RecordNoExists exception (gets thrown when the record already exists): don't you have the requirement to use a DuplicateKeyException for that situation. If not i would rather chose RecordAlreadyExistException instead of RecordNoExistsException (because now you use record numbers to see if record exists already, but maybe later you would have some unique contractor-code or room-number which is the real primary key)

I'm one of those guys that creates a DatabaseException (a runtime one): catch e.g. an IOException, wrap it in my DatabaseException and rethrow that one. if the magic cookie is wrong, i also throw a DatabaseException. All documented in my interface at each method when a DatabaseException is thrown.
I have one Exception-class for all possible trouble that can occur while using the db (i also have the RNFException and the DuplicateKeyException of course), you are creating a particular class for each possible error. So you will have a lot more classes than me

Which approach is best? I don't know. But i don't think it's a good idea to just output the errors to a console/errorfile and nothing more. if nobody is looking at console/errorfile, it may take days, weeks or even months before someone notices that something went wrong which could lead to your datafile being completely corrupted, rooms being booked 3-4-5 times, law suits against URLyBird and finally bankrupcy

Hope my comments were helpful to you (because at friday evening brains are )
Kind regards,
Roel

[Yucca Nel]

Ok thank you all for the replies but my point is this. Is it really geiving mening to your catch of the IOException if you just wrap it in a Exception class that you created? I would of thought that IOException was pretty informative as is. And if not I am still at a loss on what to do? Do I create a DatabaseException for all DatabaseRelatedExceptions and just send all my checked exceptions to that class along with wrapped rethrown checked exceptions from precoded classes?

If I do go the route of throwing all Exceptions from my database to the DatabaesException class what would be th correct way of throwing an IOException?

Would I wrap it as cause when i instantiate DataBaseException?

[Roel De Nijs]

Yucca,

One of the main reasons to wrap the IOException in a DatabaseException for me was in that way you are hiding the implementation. So it will be a lot easier to change the implementation from a file to a RDBMS where the exceptions are SQLException and no IOException.

Regards,
Roel

[Yucca Nel]

ok here is my route I chose now. I will stick with a DatabaseException class (checked Exception) and give it the three constructors that are often used.
Then I gonna wrap any inherited checked exceptions by sending them as causes along with messages to my databaseException and for any non-inherited
checked exceptions that I create I will send them to a subclass of databaseException. Thus all of my Exceptions will have a new reusable class).

Final question I see some people using exceptional messages as Static utility strings. Is there a reason? Is it common or is it lazy? it looks pretty lazy to me like they dont wanna write the error message.

[Jayesh A Lalwani]

There are pros and cons to wrapping exceptions

Pros:- the implementation is hidden. Your calling program doesn;t need to change whenever you change the implementation of the classes.

Cons:- Loss of flexibility and the overhead of wrapping. Exception gets caught and rethrown at every point which puts a load on Java. Catching and throwing exception isn't cheap (Hopefully, exceptions are being thrown once in a b


Generally, I try to wrap exceptions when classes are loosely coupled together, and simply let the exceptions pass through when there is tighter coupling.

Besides, this makes me crazy

com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
caused by
com.company.project.componentA.ClassB
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
caused by
com.company.project.componentA.ClassC
com.company.project.componentA.ClassB
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
caused by
com.company.project.componentB.ClassD
com.company.project.componentA.ClassC
com.company.project.componentA.ClassB
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
caused by
com.company.project.componentB.ClassE
com.company.project.componentB.ClassD
com.company.project.componentA.ClassC
com.company.project.componentA.ClassB
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
caused by IOException

WTF, dude? just give me this

com.company.project.componentA.ClassC
com.company.project.componentA.ClassB
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
caused by
com.company.project.componentB.ClassE
com.company.project.componentB.ClassD
com.company.project.componentA.ClassC
com.company.project.componentA.ClassB
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
com.company.project.componentA.ClassA
caused by IOException

It gives me the same amount of info

[Yucca Nel]

Yes it mad me eyes sore too. But if wrapping exceptions is a hit on performance then it could be said dont do it and let it bubble but this is the SCJD so bubbling is not an option.

[Roel De Nijs]

Yucca Nel wrote:Final question I see some people using exceptional messages as Static utility strings. Is there a reason? Is it common or is it lazy? it looks pretty lazy to me like they dont wanna write the error message.

I guess you mean something like this

  throw new DatabaseException(ApplicationConstants.FILE_NOT_FOUND, fne);  

and then in ApplicationConstants

  public static final String FILE_NOT_FOUND = "File not found." 

One reason to do something like that i can think of is to make it a bit easier to i18n the application

[K. Tsang]

Hi there, personally I don't suggest wrapping exceptions with another broader exception and printing the stack trace won't be useful to the user (maybe the developer for debugging). If stack traces are used why not use the logging API instead.

Since end user only see the GUI and not the command prompt, depending on the severity of the exception I use a dialog pop up to indicate "user-friendly" error messages. Severity depends on you really. Eg if the file can't be loaded or connected because of the server not started, I did error popup saying "Server not started' and exit the app. This ultimately means someone better start the version...

Less severe errors may be updating/reading records, if it's a locking issue (hopefully not) you may say something like "Unable to update due to blabla". I hope you get the idea.

[Yucca Nel]

Its been suggested not to use logging in the SCJD as it could lead to overcomplicating things but thanks for the advice. In non SCJD application then I will try your advice.

[Kevin Florish]

Hi Yucca

Just as an aside about using logging in SCJD. I used logging extensively in SCJD and wrote all log messages to a single file. For me this did add
more code/complexity to the project.

As an upside the logging showed me clearly my locking mechanisms and was a valuable debugging aid.

As the aim of SCJD is all about learning some of the features of Java and widening your knowledge base I felt the trade-off between complexity
and learning was justified and the logging actually saved me a lot of time in the long run

Cheers Kevin.