I would like to throw IOException from the data class by wrapping it in a special exception such that it can be caught and the IOException extracted in a typesafe manner. What do you think of this attempt:
The requirements state that the zero-argument and String argument constructors must exist, but would I, by making them private, risk automatic failure? If I don't make them private, I lose the type safety benefits (unless I do some really awkward stuff).
The idea is that a client can then (at least in my opinion) rather elegantly convert the DuplicateKeyIOException into an ordinary IOException:
The same thing could be done by suclassing RuntimeException.
I basically did the same thing with RNF exception as well. Needed to throw a different exception to classify it as a different type of exception.
I understand why you want the client to convert the exception to an IOException. The way I build my program I assume an IOException means a unrecoverable faliure(beccause in my cause the normal opperation of the program cannot cause IOExceptions) and just carry along the information.
If you chose to encapsulate exceptions in Data by extension just do it by extending it normally and using like you would a normal exception(like RNF). Thats my humble opinion wait till peter chimes in. [ October 20, 2004: Message edited by: Inuka Vincit ]
I have the B&S Contractors assignment, and the following supplied interface to be implemented by Data.java:
I am also dealing with the IOException problem. Initially, I didn't want to use a runtime exception (like many people in this forum are doing), but rather use exception chaining. I have finally decided to use a runtime exception, however, based on the following reasoning:
1. An IOException can cause a record to not be found, and therefore it would be justified to extend RNFEx to IORNFEx. But an IOException does not cause a DuplicateKeyException.
2. What about the find(String criteria) method, that doesn't throw any exceptions? In my implementation, the find method performs IO operations, and therefore if I can't throw any exceptions from find I'd be forced to deal with them right there, which I don't want to do.
So, for the sake of consistency, I have decided to jump on the runtime exception bandwagon. There are many threads discussing this, most of which explain the reasoning for using runtime exceptions much better than I do.
What do you think?
B.S. University of Wisconsin<br />SCJP 1.4 (85%)<br />SCJD 1.4 (92%) B&S Contractors
posted 15 years ago
Nicky:The requirements state that the zero-argument and String argument constructors must exist, but would I, by making them private, risk automatic failure? If I don't make them private, I lose the type safety benefits (unless I do some really awkward stuff).
Inuka:I basically did the same thing with RNF exception as well.
My concern here is in particular the private zero-arg and String-arg constuctors. Are you recommending that they should be public?
Inuka:The way I build my program I assume an IOException means a unrecoverable faliure(beccause in my cause the normal opperation of the program cannot cause IOExceptions) and just carry along the information.
If I understand you correctly, you subclass e.g. DuplicateKeyException and, for example, throw new DuplicateKeyIOException(caughtIOException) when an I/O error occurs in Data. Then, somewhere in your client or GUI, you catch DuplicateKeyIOException, and when you do, you treat it like a generic (although fatal) Exception? Is this right? It is a workable solution I think, but in my case, I would like to avoid it, because I have a slightly higher-level interface than DBMain where I don't declare DuplicateKeyException (duplicate keys can never occur in my implementation).
Jared:for the sake of consistency, I have decided to jump on the runtime exception bandwagon.
Yes, you point out good arguments for the runtime exception approach, and I may choose to jump the same bandwagon. But my concerns are about unwrapping the IOException in a typesafe way, and I find the most elegant way to do it is by restricting the constructors of the DuplicateKeyIOException (or whatever) such that the "cause" exception is absolutely guaranteed to be an IOException. But this puts me in a worry about the "exceptions must have zero-arg and string-arg constructor" requirement. This issue is the same whether you use checked or unchecked exceptions.
Inuka:What do you think?
Runtime exceptions are fine in this context, and as you point out, other topics address the issue in much detail. If I were to sum up the topics, all approaches are evils in this context, and it a matter of taste which we consider the lesser evil:
Throwing RecordNotFoundException/DuplicateKeyException because of an I/O problem is misleading, no matter whether you do subclassing, chaining, or both. The advantage, however, is clients are forced to deal with these checked exceptions, and even in the worst case scenario where a client treats an I/O problem as if a duplicate key were created, the consequences will likely be limited to a graceful abort of the operation and a (possibly misleading) error dialog shown to the user. For a worst case scenario, this is very good.
Throwing an unchecked exception because of an I/O problem has the potential to crash the client. The advantage, however, is that it is not misleading.
No matter if you go checked or unchecked (or use special error return values such as null or negative numbers), your client will have to read your documentation to achieve the best error handling possible.
And (as is the case for you), if one of your methods don't throw any checked exceptions, then checked exceptions are naturally not a consistently applicable option.
These are very interesting topics, but since they are addressed in so much detail, my primary concern in this topic is the typesafe (or not) unwrapping of the nested IOException. [ October 20, 2004: Message edited by: Nicky Bodentien ]
Self destruct mode activated. Instructions for deactivation encoded in this tiny ad.
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop