[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