File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Custom Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Custom "assert" method - bad programming style?" Watch "Custom "assert" method - bad programming style?" New topic
Author

Custom "assert" method - bad programming style?

Michal Charemza
Ranch Hand

Joined: Jul 13, 2004
Posts: 86
Hi all,

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.

Michal
Uwe Schäfer
Ranch Hand

Joined: Mar 15, 2005
Posts: 52
Originally posted by Michal Charemza:


I was wondering if anyone thought such a design is a bad one and why.


i dont think so. i did this as well.


scja|scjp|scjd|scwcd|scbcd|scdjws|scmad
Michal Charemza
Ranch Hand

Joined: Jul 13, 2004
Posts: 86
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.

Thanks,

Michal.
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
I know I specified checked exception, but what about unchecked exceptions? Would it be ok for them as well?

Hi Michal,

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.

Frans.

* 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
Uwe Schäfer
Ranch Hand

Joined: Mar 15, 2005
Posts: 52
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.
Michal Charemza
Ranch Hand

Joined: Jul 13, 2004
Posts: 86
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.

Michal
Mihai Radulescu
Ranch Hand

Joined: Sep 18, 2003
Posts: 918

Hi,

Michal

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.



becomes



I hoper this help.
[ June 20, 2005: Message edited by: Mihai Radulescu ]

SCJP, SCJD, SCWCD, OCPJBCD
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Custom "assert" method - bad programming style?