Is it bad programming practice to make a (private) method that just asserts that some condition is true, and if it isn't it throws a checked Exception?
i.e. say in the update(int recNumber) method have:
and assertRecordExists is a method that does nothing if the record exists, and throws a RecordNotFoundException if the record doesn't exist.
There may be other issues here regarding locking and/or other exceptions and things which I havn't thought about, but just in case these issues do not impede me, I was wondering if anyone thought such a design is a bad one and why.
I was wondering if anyone thought such a design is a bad one and why.
i dont think so. i did this as well.
Joined: Jul 13, 2004
Thanks for your reply. I know I specified checked exception, but what about unchecked exceptions? Would it be ok for them as well? Specifically I mean whatever unchecked exception I will throw if a thread is trying to update/unlock without owning the lock on a record. I was considering making a similar assertCurrentThreadOwnsLock method.
I know I specified checked exception, but what about unchecked exceptions? Would it be ok for them as well?
For checked exceptions it seems OK to me. In fact I did the same thing. For unchecked exceptions* I feel that you'd better use the Java assert mechanism, since that demonstrates that you know how to use the language's features. It also solves your problem of what exception to throw.
* I am assuming that when you consider throwing an unchecked exception, that that means it is a sort of unrecoverable situation anyway. [ June 17, 2005: Message edited by: Frans Janssen ]
SCJP 1.4, SCJD
Joined: Mar 15, 2005
Originally posted by Michal Charemza: I was considering making a similar assertCurrentThreadOwnsLock method.
from my POV an assertion (std. java assertion or own assertXY method) should be used in order to be sure that necessary preconditions that you do expect to have met by surrounding/using code actually are.
hummm. strange sentence
i mean... i use assertions where i am kind of sure that things MUST (or CANNOT) happen unless programming errors.
example: is supposed to be ok whereas is not. as assertions can be turned off a client of this class may not be aware of a misuse/broken contract of this method then.
the main difference though between your selfmade assertion-method and the assert keyword (i suppose) is that it cannot (and maybe should not) be turned off. so if you�re unsure about the name, i would just call it "enforceCurrentThreadOwnsLock" no matter what kind of exception is/can be thrown.
Joined: Jul 13, 2004
Originally posted by Frans Janssen: I feel that you'd better use the Java assert mechanism, since that demonstrates that you know how to use the language's features.
I was going to throw a RuntimeException if a thread tries to unlock a lock it has not locked. It is either this or throw a RecordNotFoundException, which I don't think is suitable (this choice is because of the specified interface in the instructions).
I don't think an assertion is suitable in this case because as Uwe says assertions can be turned off. Thus a thread may return successfully from unlock() when it never had the lock in the first place.