"MikkelFJ" <mikkelj-anti-spam / post1.dknet.dk> writes:

> > I don't want to be contentious, and I'm certainly willing to be swayed
> > on this issue. Could you give a real-world example of this?
> 
> A database operation where Rollback is not supported. Rollback is only
> called in case of an error. Errors happen infrequently. The function will
> happily run on a lesser database interface until an error occurs.
> Then at failure, the database is left in some strange state.

OK - interesting example.

You have a routine that performs some critical function in a database,
and that database is passed in as a parameter. During the middle of
processing, that routine might want to invoke a rollback operation on
the database. If the parameter passed in does not support rollback,
then you (and the database) are hosed.

So, the conclusion is that the routine you're writing should check to
make sure that the database passed in supports rollback.

Or should it? Should routines that perform business logic be
concerning themselves with low-level database characteristics? I
honestly don't know. I can certainly see what you're getting at. But
at the same time, another part of me is saying: this application is
structured wrongly. I wouldn't want to get into that position, for a
whole number of reasons. For example, this routine that decides not to
proceed if there's no rollback available might itself be part of some
larger overall transaction. If it decides to abandon processing
because rollback is not available, then its action has actually
_caused_ a database corruption, as the transaction will be only
partially complete.

So, I'd suggest that coming across this kind of situation, where you
feel that you need parameter checking, might be a flag to make you
stop and think. Could I restructure my application to remove the need
for this? What are the reasons I got into this particular situation? 

I'm certainly not saying you can always do something about it, and I'm
not saying that you should never test the capabilities of a parameter.
But I think you need to do it far less that people might at first
imagine.


Regards


Dave