At 09:33 AM 6/1/00 -0700, Glebas Paulevicius wrote:

>Jim,
>
>If I want to come up with an elegant C++ code - I follow two basic rules:
>What I would love to see is:
>
>main (int argc, char **argv)
>{
> try
> {
> Connection connection = createConnection();
> Parameters parameters;
> parameters.putValue ("user", "jas");
> parameters.putValue ("password", "in-your-dreams");
> connection.openDatabase ("d:\\OdbcJdbc\\IscDbc\\employee.gdb",
>&parameters);
> PreparedStatement statement = connection.prepareStatement(
> "select first_name, last_name, emp_no from employee where first_name
>

<snip>

The above requires that the compiler have access to the implementation
of all the classes in the object model, which isn't possible. The
only way to use an instantiation of an abstract class is through a
pointer.

I think what you are suggesting is a wrapper around the wrapper. I
certainly don't have any objection to somebody doing this, but I don't
think it an essential part of the object model.

>In your code:
>
>> resultSet->release();
>> statement->release();
>> connection->close();
>
>Why don't you call these release()s and close()s inside catch?

Lazy and venal.

>How do you know if resultSet was allocated before exception was thrown or
>after?

The assumption has to be that the PreparedStatement::executeQuery()
cleans up after itself. But it's moot. A ResultSet can be returned
only if an exception is not raised.

>How do you know if connection was opened before exception was thrown or

after?

>

If an exception is raised, in all cases, the offending call "didn't happen."

>In my understanding, nearly any method in database wrapper may cause an
>exception.

Yup.

>
>Yes, Java does it all for you,
>Yes, it is a little more job for C++ programmer,
>But if you do JDBC with C++, agree to mimic Java someplace :)
>Then you come up with more elegant, safer solution
>for application programmer.
>

I appreciate your motivation, but your C++ style is not everybody's
C++ style. As you point out, you can define your own wrapper. But
the implementation classes have to be based on the abstract classes
that define the API.

>>ResultSet::wasNull() returns true/false.
>
>why "was"? I would say "isNull".
>

'Cause that's what the JDBC specification says. The basic rule
is "no arbitrary differences."

Jim Starkey