• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

How you guys handle exception?

 
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have question about handle exception.
According to DB.java interface, we are limited to throw only several exception like RecordNotFoundException, SecurityException.
How about the IOException might be occured when accessing db file?
do you guys log into a text file or print it on console?
How do you handle these exception?

Thanks

Lee
 
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, I am following a very simple approach, I throw a RecordNotFound exception, and I pass the IOException as parameter for the RecordNotFoundException constructor, so that I still keep information of the underlaying cause of error.

Somewhat like this:



After all, if an IOException happens while trying to read or write a record I may just as well say the record was not found.

I hope that helps!
[ April 23, 2008: Message edited by: Edwin Dalorzo ]
 
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Edwin Dalorzo:



Honestly, I would be careful with this approach. An IOException is not A RecordNotFoundException. Also, when it is time to catch this exception, how will you know if it was an IOException that occurred and not a RecordNotFoundException? I personally didn't have this problem because I have a method that loads the database records into a Map structure; this way, the methods provided in Sun's interface only throw exactly the exceptions of their signatures.
This is just my personal opinion.
 
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Chih,

You can log IOExceptions (which might also include FileNotFoundException - fnfe, and EOFException - eofe).

However certain conditions can cause you to wrap some exceptions in any of those thrown by your interface.

For instance if you are doing a find and you encounter an eofe, the first thing you should do is to ascertain that the current read/write position of the file is greater or equal to the file length, if it is not then your your file might just be corrupted.

If the current read/write position is less than the file length and your record was not found then you must throw a RecordNotFoundException, and so no...

good luck
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To Roberto Perillo

I am trying to understand your approach to the handling of IOEXception according to what you wrote.

You said:


An IOException is not A RecordNotFoundException.



That is correct, however that does not mean that one cannot warp an IOException into RecordNotFoundException. This is a very typical approach in many other APIs.

You also said:


how will you know if it was an IOException that occurred and not a RecordNotFoundException



Well, if you wrapped the IOException into a RecordNotFoundException that you can use the getCause() method, which would give you access to the original IOException error.

Finally, you said:


I personally didn't have this problem because I have a method that loads the database records into a Map structure; this way, the methods provided in Sun's interface only throw exactly the exceptions of their signatures.



Ok, but I guess you still have to handle IOException when you read your database file and load the info into a map. So, here the question is, what do you do to deal with IOException. This take us to the original question again. Does it not?

I know that just logging the exception is not an option. It must be either thrown again or handled, since it is a checked exception. However, I still cannot understand, from you answer, how you handled this issue.

Any thoughts or recommendations?
 
Chih-Wei Lee
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks all your response, very useful.
Eric,
Some exception message might be helpful to user but some aren't.
how do you handle those exception which are not necessary showed to user?
I consider to log these error in a text file but I don't think examiner will take a look this log file.

Thanks

Lee
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To Chih-Wei Lee

You said:


Some exception message might be helpful to user but some aren't.
how do you handle those exception which are not necessary showed to user?



You are talking about exceptions as if they were created to display error messages to the user. I think that approach might lead you to incorrect designs.

The message of an exception could be different than what you actually display to the user. The message displayed to the user could be more friendly than the message contained in the exception. Typically the contents of the exception are intended to reveal the underlaying causes of the error. And you can used them to enforce the handling of possible error conditions.


I consider to log these error in a text file but I don't think examiner will take a look this log file.




You can log all the exceptions if you want, this still will not save you from doing something about the IOException that you asked at the beginning.

For instance, if you invoke the readRecord methid, it fails to read the file then you can log the exception, but still you must either rethrow the IOException or wrap it into a RecordNotFoundException, because you cannot simply ignore that it happened.

So, here I am just trying to make sure you are not suggesting to ignore the exceptions, because that would be a really, really bad idea.
 
Chih-Wei Lee
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, if there is a IOException occured during reading db file and you display all exception message to user even it's friendly.
What do you expect user to do?
Only two things user can do, either try again or close your system.
That's why I said I consider to log those exception which user can't fix by changing their behavior.
Actually, in this case, if examiner got a critical exception like IOException when he test the assignment, you just got a assignment failure and resubmit it.
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, Chih-Wei Lee


Let's see an example of what I think your are suggesting.



Ok, in this case, if I simply log the IOException, then no error is thrown at all, and what will this method return? A null array? Is that what you are suggesting?

In my approach this is a RecordNotFoundException with a wrapped IOException. If the RecordNotFoundException reaches the UI, then I may show a dialog box with an internationalized error message. Somehwat like: "The record X could not retrieved" and perhaps a details button where the user can take a look at the detailed exception tree with the option to copy it to send it to the system administrator.

In your approach, the user will never know why system failed unless, of course, he know where the log file is, and how to read it. And of course, as long as the user knows English, which is the typical language of the IOException details.

I have the impression that logging an IOException and then ignoring it happened is probably not the best approach. If this exception happened something serious is going on.

I would asume three different alternatives:

1. Wrap it into a RuntimeException
2. Wrap it into a RecordNotFoundException or
3. Propagate it.

In all this cases, it can still be logged.

For me, just logging the exception is like absorbing it and forgetting it happened.

At any rate, this is just my opinion. As I said before, I had not yet finished my assignment and I cannot defend one approach over another as the right implementation choice. In this case I am just using my common sense.

Good luck, Chih-Wei Lee. And please, let us know how it turns out once you have received the qualification.
 
Chih-Wei Lee
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, I agree with you to show all messsages to user so that they can contact system administrator for advanced help.
I don't like logging either. I just want to find a reasonable approach to handle all exception.
But I would say wrap exception into RuntimeException is a better method than into a RecordNotFoundException.
Since Sun has restriction about it
"Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file"

Anyway, thanks for your response.

Lee
 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, the requirement as you well said mentions that...


"Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file"



Thereofore, if I do so, and besides this, I wrap IOException into the RecordNotFoundException I would still be fullfilling the requirement, right?

Since the skeleton code for RecordNotFoundException and SecurityException are not provided, I guess there are certain liniencies that I can have.

Or at least that's what I hope. I will let you know how it turns out in my case after I have submitted the assignment.
 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Edwin Dalorzo:
Well, I am following a very simple approach, I throw a RecordNotFound exception, and I pass the IOException as parameter for the RecordNotFoundException constructor, so that I still keep information of the underlaying cause of error.

Somewhat like this:



After all, if an IOException happens while trying to read or write a record I may just as well say the record was not found.

I hope that helps!

[ April 23, 2008: Message edited by: Edwin Dalorzo ]


Hmm. My B&S assignment says "...unimplemented exceptions ... Each must have a zero argument constructor and a second constructor that takes a String that serves as the exception's description."
It does not directly prohibit other constructors, but somehow I feel uncomfortable about your way of exception wrapping.
 
Chih-Wei Lee
Ranch Hand
Posts: 129
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree!
Eventually, I create a custom exception class which extends RuntimeException, and wrap all of basic exceptions like IOException into it.
Then catch these RuntimeException at GUI.
 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I followed the same exception wrapping approach during one of the feature implementation in my company project. I call it as 'Exception Conversion'. This turned out to be easy and effecient implementation specially at the application level.

Suppose you have to handle Exceptions coming from FileIO,DB,Network and other few third party tools. like:
NullPointerEx(Java), FileNotFoundEx(FileIO), RecordNotFoundException(DB)
JSCHException(3rdPartyTool), SocketEx(Network IO) etc..etc.
Objective is to:
'Never show these exceptions as it is to user. But keep him informed about the root cause of the error'
approach is:
'catch,convert,format once, keep propogating till it reaches UI.'

To achieve this, wrap all these exceptions into a custom exception - suppose your application is called ABC, then custom exception could be AbcException.
This custom exception should be associated with application specific, end user understandable, context specific error message string.
like: "ErrorCode 001:The record X could not be retrieved. Try again later." (in case of unknown error scenarios)
or 'ErrorCode 002:The record X is not found in the database' in case of "RecordNotFoundException'

Better to derive custom exception from RuntimeException. It makes exception handling simpler.
This way, only core interface methods have to catch and convert exceptions and simply propagate them. Business logic methods can be kept cleen by doing less with catching and processing these exceptions.
 
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Naveen Hegde:
(...snip...)To achieve this, wrap all these exceptions into a custom exception (...snip...)



Edwin Dalorzo asks:Is that what you are suggesting? on Wednesday, April 23, 2008 3:48 when: Chih-Wei Lee stated Only two things user can do, either try again or close your system. just before on Wednesday, April 23

What this leads to for most situations is if the exception is an exceptional exception, which is only handled by fail-fast behaviour.

That can be a screwed up mess, therefore if there are any value in any of the data, protection by encipherment is needful as part of the orderly shutdown. You may wish to consider that in your design-review process.

I did implement the design you suggest early in concepting and the design has proven totally effective for entire codebase.
 
Naveen Hegde
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Nicholas,
I didn't get your point 'That can be a screwed up mess'? can you elaborate a bit more?
For your question, my answer is:
Yes. I do suggest similar solution. Lee's Scenario is:
You can throw only (as ristricted by Sun)
1) RecordNotFoundException
2) SecurityException
But IOException is inevitable in this code block. IOEx indicates operation failure and you cannot duck it.
Logging to file will not help end user! Somehow IOException should get a royal treatment.
So in this case, throwing RecordNotFoundException is the closest solution i guess.(as Edvin suggested in the begining)
This is similar to 'Convert,Format,Propagate' approach right?
 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is a case when wrapping IOException in RecordNotFoundException or SecurityException is not a good idea.

You want to update a record. You read it and know that it exists. You also have a lock on it (no security issue). Just when you actually write the data bytes to a file you encounter an IOException.

How can you throw RecordNotFoundException or SecurityException? It would be misleading.
 
Hold that thought. Tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic