cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher McKenzie" <>
Subject RE: Performance of get
Date Tue, 27 Oct 2009 20:32:10 GMT
I see.  This is indeed unfortunate and understandable.  I'm sorry for harping on this, I know
that the project is young, and I thought it would be important to opine early on.

I've found in API design, that if you don't make it idiot-proof and airtight, you will feel
worlds of pain literally, forever.  For a web 2.0 example of this, look up resig's jquery
lectures although there are many other examples of people getting themselves in trouble for
not treating their API as if it was a truckload of diamonds.

I still think that the exception handler invoking in this case may lead to large-scale improper
use especially when less skilled people start using the technology --- which will be inevitable
(and why I gave the PHP number).

I wish there was a different way of dealing with this problem that wouldn't be susceptible
to so much theoretical misuse but given what you said, I have no solution other then to invent
some reserved value that is *special for cassandra* - but this also sounds like it will lend
to a potential travesty of poor design.

Any ideas?  Thanks.

-----Original Message-----
From: Jonathan Ellis []
Sent: Tue 10/27/2009 1:14 PM
Subject: Re: Performance of get
On Tue, Oct 27, 2009 at 2:00 PM, Christopher McKenzie
<> wrote:
> Exceptions are a special feature of languages often with their own keywords, primitives,
and usually chapters in books.  I don't profess to be an expert in the various exception
models for all the versions of various implementations of C++, Java, Python, PHP, Ruby, Erlang,
Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml that thrift supports.  But I would claim that,
with such a large heterogeneous and dynamic support base, one should use something as varied
and unpredictable as the exception handling models with great care and I don't "personally
feel" that the understandably expected error case of Get should be escalated to be handled
by this mechanism.

There are basically two sane options for looking up a key that doesn't
exist.  One is to return null or the equivalent; the other is to raise
an exception.  There are pros and cons for each, and examples of
languages whose stdlib behaves either way.  So a blanket Exceptions
Are Not Idiomatic For Key Lookup statement is misguided.

And as it happens, Thrift does not support returning null values at
all, so from there the natural choice was obvious.


View raw message