• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Custom "assert" method - bad programming style?

 
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Michal Charemza
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Uwe Schäfer
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic