Ed,

>I meant that it's advised to make code error-proof...

I certainly agree that anticipating possible errors and coding for them is a good practice.

>... My major point was that if code (class) is encapsulated (i.e. as you said, it doesn't depend on any state of databases or tables outside of itself) then you don't need in private datasession at all.

The encapsulated code may not DEPEND on any state of databases or tables outside of itself, but if may CONFLICT with the state of databases or tables outside.

The example I referred to of encapsulating old code inside methods of Session subclass is done precisely for the purpose of enabling that code to be used anywhere in the application without any chance of its data-handling activities stepping on the data environment outside of the class.

This allows you to quickly take, for example, large blocks of horrendous code that select numbered work areas, open and close tables and or databases, and so forth. Encapsulating it inside Session is a quick and easy way to reuse that code safely. It might be better to complely rewrite it, but sometimes isolating it is the best incremental step to take, even if it will be rewritten later.

In the scenario described above, I don't bother to explicitly set datasessions back and forth because the Session class handles that very well.