Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: Nesting exceptions

 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I MUST use the DBMain interface which defines the exceptions I must throw. Methods like read() throw RecordNotFoundException. My problem is basically I want the method to also throw IOException. Im assuming I cant change the interface so that aint happening.
So I end up having to use try/catch inside my read method and catching the IOException, and im not 100% sure what to do with it. I wont get an IOException because I read beyond the file as I check the limit and position before I read to the buffer, so if I get an IOException it will be for unforseen reasons (File being somehow damaged, deleted etc) and obviously on a catastrophic failure like this I do not want to swallow the exception.
My choices seem to be:
1) Nest the exception in a RecordNotFoundException..... dont like this.
2) Throw an error an shut the application down .... dont like this.
3) Hope someone here has a brilliant and yet simple idea .... love this one.
Option 2 seems too severe, but option 1 seems too light. I mean we are talking about something major has gone wrong accessing the datafile (assuming my code is safe and I have not tried to read a byte beyond eof).
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Morgan,
I don't have anything brilliant yet simple to say this morning (in fact, I don't even have anything brilliant but complicated either), so I can't contribute any good ideas to option 3. However, I do like option 1 for the following reasons:
1) It really is a record not found situation. Assuming the record number was a valid record number, the fact that something went wrong when attempting to read it means the record was, in fact, not found. If the record number wasn't a valid record number, then of course, record not found is a very sensible exception in that case as well.
2) Let's say that the real cause of the record not being found is some IOException. There's nothing preventing you from encapsulating the IOException inside a RecordNotFoundException using exception chaining. The client can catch the RecordNotFoundException and do a getCause() call to get at the cause of the record not being found. Maybe if the cause is an IOException then you could treat that as a fatal error.
3) Looked at through the right perspective, doesn't the RecordNotFoundException cover everything that could possibly go wrong in the read method? I mean if the method is not able to return a valid record, then wasn't it the case that the record was not found? (I guess this is basically the same argument as in 1 -- see, I'm just not being very simple this morning, let alone brilliant. )
Hope this helps,
George
[ January 23, 2004: Message edited by: George Marinkovich ]
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Morgan, hi George,
I have a quite similar discussion with Phil in this thread.
Perhaps it can help you,
Greetings
Ulrich
 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I guess youre right George, but it still feels a little like a patch
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Morgan,
Originally posted by morgan bath:
I guess youre right George, but it still feels a little like a patch

I can't disagree with that sentiment, because, well, it is a patch. It's not a particularly elegant solution, but it's one way to use the interface supplied by Sun without making any changes to it.
Another, perhaps more elegant, solution is to create your own replacement interface. Data would still implement the DBMain interface as required, but it would also implement your new replacement interface (although perhaps not explicitly). Then you could abandon the DBMain interface and use your replacement interface in the rest of the code.
Hope this helps,
George
 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually ive done that: used two interfaces. My database client offers only 4 methods: getRecordSet(String[] criteria), getSchema(), reserve(recNo), release(recNo).
One thing you mentioned was the fact that I should not change the DBMain interface. You are talking structurally right? I changed the comments from simple lists of // comments to JavaDoc comments. They are not that anal right?
Actually DBMain did not come with the assignment as a file, it was simply wriotten inside the html instructions
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Morgan,
To clarify the issue, yes, in my opinion you can change the comments that accompany the interface supplied by Sun so that they meet the javadoc requirements. It's also true that Sun supplies the interface as part of the instructions.html file, not as a standalone Java source code file.
Hope this helps,
George
[ January 26, 2004: Message edited by: George Marinkovich ]
 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah it helps thanks. Ive decided to have an adaptor pattern between the Data object and the client. I really dont want to have lock and unlock public, but obviously I have to leave them on the Data object.
So Data now implements DBMain and DBClient, and I have an adaptor class that implements DBAdaptor. DBAdaptor and DBClient are actually identical, but obviously I should avoid using the same interface for the adaptor as for the database.
This leaves the ICKY situaion of my GUIs using the adaptor which forces locking, and yet leaves Data open for the 'old' application and offers but does not force locking. If this was a commercial project id die of shame
 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually I just had an idea that instead of the adaptor being an interface it could be an abstract class that uses DBClient. That would remove the need for a duplicate interface. Then I would simply extend the abstract adaptor for either local or network use. I kinda like that idea. But ill have to think that over as i've tended towards interface use in the past and cant remember using an abstract class ever.
Then id have:
Data implementing DBMain, DBClient
abstract DBAdaptor implementing DBClient and containing a reference to Data
Then LocalDBAdaptor and RemoteDBAdaptor extending DBAdaptor.
That would prevent anyone altering the GUI always links to an adaptor and not Data (thus preventing mischief through the old DBMain interface remotely) .... unless I missed something.
Anyways, ive now hijacked my own thread for a totally new subject
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic