[ZOOM] Re: C++ error handling

Heikki Levanto heikki at indexdata.dk
Fri Nov 2 11:24:58 CET 2001


On Thu, Nov 01, 2001 at 04:43:39PM +0000, Mike Taylor wrote:
> 	if ((rs = conn->search(query)) == 0)
> 	    return conn->errcode();
> or
> 	try {
> 	    rs = conn->search(query);
> 	} catch (error) {
> 	    return error->errcode();
> 	}
> 
> Well, I know which I prefer, but maybe I'm very old-fashioned :-)

I have a small preference towards error codes, but that is not an important
point for me. What I see as important is to make a clear decision about the
way we handle errors, and stick to it consistently! 

 
> > I do not see how I can pass options to a connection before
> > connecting.  I need to pass authentication information and proxies
> > to them. You don't mean that I should use global options for that?
> 
> Yes, that's (roughly) the intention of the abstract API.

I don't like this. It may work well if you plan to have everything in a
single thread, but heaven help us if we ever need to have two threads, both
of them starting connections, and setting their own values to the same
global options. 
 
> This may be a reason to reconsider the abstract API -- not just the
> C++ binding.  The answer in the Perl binding, which I plan to
> retro-engineer into the "advanced" document of the API, is that you
> make a Manager object, set the options in that, and then get your
> connection object from mgr->connect(), but that may not be ideal for a
> variety of reasons.

As I see it, it makes no difference if the global options are moved inside a
manager class, if that stays as global. 
 
> Again, in the Perl version, if you don't want to mess about with
> managers, you can throw an arbitrary number of options right in with
> the "new connection" call, as in:
> 
> 	my $conn = new Net::Z3950::Connection('www.indexdata.dk', 210,
> 					      user => 'mike',
> 					      password => 'foo')
> 	    or die "can't connect: $!";

Ouch! This will be hard to do in C or C++. Don't even mention varargs,
that is not the way we should go. If anything, pass one char* that contains
all the options ("user='mike'; password='foo'), but that stinks too.
 
> > Generally, I think it would be useful to have a comment at the end
> > of the interface file with a simplified example of how to use it:
> > connect. search, get record, and do something with it.
> 
> Most surely the binding specification should include such things, and
> website should have plenty of sample clients to download an run
> against in-development implementations.  They don't belong in the
> header file, though.

I don't want a whole schoolbook in the header file, but one example of (say)
12 lines could not hurt too much. (Don't tell me you can not make it in 12
lines, zoom was supposed to be a simple API!)

I believe the header file for C++ should give just enough information that a
programmer can use it. 
 
> I take your point.  These comments are intended not to explain what a
> VBC is but to indicate which of our classes fall into this category.
> Could you suggest improved wording to achieve this?

I think any experienced C++ programmer will notice a virtual base class from
the fact that all methods have this =0 at the end. If anything, a really
short comment /* virtual */ should be sufficient. 

-H


-- 
Heikki Levanto            heikki at indexdata.dk            "In Murphy We Turst"



More information about the ZOOM mailing list