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 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 ]
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.
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.
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.
Uwe is right in your presumption
You can use the asserts to check if some state(s) are archived.Under normal circumstances the o != null is always true.
but if you make a programming mistake and you forget to build the vector instance(in your example) then it make sense to throw an exception.
I hoper this help.
[ June 20, 2005: Message edited by: Mihai Radulescu ]