[prev in list] [next in list] [prev in thread] [next in thread]
List: cassandra-dev
Subject: Re: Column assert
From: Edward Ribeiro <edward.ribeiro () gmail ! com>
Date: 2009-06-17 0:51:52
Message-ID: 123dcca0906161751n77370b38r7e8e607ee6164faa () mail ! gmail ! com
[Download RAW message or body]
That's alright.
Edward
On Tue, Jun 16, 2009 at 9:45 PM, Jonathan Ellis<jbellis@gmail.com> wrote:
> checking user input is done with explicit if statements; verifying
> internal assumptions is done with asserts. Column is not a
> user-facing class (that would be column_t).
>
> -Jonathan
>
> On Tue, Jun 16, 2009 at 7:31 PM, Edward Ribeiro<edward.ribeiro@gmail.com> wrote:
>> Dear developers,
>>
>> I saw the following piece of the code in the Column class:
>>
>> Column(String name, byte[] value, long timestamp, boolean isDeleted)
>> {
>> assert name != null;
>> assert value != null;
>> [ ... ]
>> }
>>
>> Well, the assert is a debug facility and it should not be used in
>> production code, because it only throws an exception when the code is
>> run with the -ea switch. There are other classes that follow the same
>> behaviour in Cassandra code base. If this is being used in place of a
>> null checking "if" statement then I would be glad to submit a couple
>> of patches to fix that.
>>
>> By the way, I saw that Cassandra project currently uses the very good
>> google collections library. Therefore, the code can become even more
>> succint like:
>>
>> import static com.google.common.base.Preconditions.*;
>>
>> [...]
>>
>> Column(String name, byte[] value, long timestamp, boolean isDeleted)
>> {
>> assertNotNull(name,"Column name cannot be null!");
>> assertNotNull(value, "Byte array cannot be null!");
>> [...]
>> }
>>
>> Best regards,
>> Edward
>>
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic