Re: [Bigdata-developers] defensive code?

[Jeremy J C. <jj...@sy...>]

I modified this to use asserts and committed as r7431 please let me know if this was inappropriate.


Jeremy J Carroll
Principal Architect
Syapse, Inc.



On Oct 2, 2013, at 9:59 AM, Jeremy J Carroll <jj...@sy...> wrote:

> 
> Hmm
> 
> I wonder if github only shows you the code if you log in …
> 
> 
> It is, e.g., this in AssignmentNode, which overrides several methods and calls super to verify that the first arg is always a VarNode, which is the class invariant that failed.
> Sounds like maybe I should I rework to turn checkFirstArg unto an assertion and then inline checkFirstArg
> 
> 
> +  
> +
> +
> +  private void checkFirstArg(final BOp newVal) {
> +    if (!(newVal instanceof VarNode)) {
> +        throw new ClassCastException("First op in AssignmentNode cannot be "+newVal.getClass().getName());
> +    }
> +  }
> +
> +    @Override
> +    public ModifiableBOpBase setArgs(final BOp[] args) {
> +      checkFirstArg(args[0]);
> +      return super.setArgs(args);
> +    }
> +    
> +
> +    @Override
> +    public ModifiableBOpBase setArg(final int index, final BOp newArg) {
> +      if (index == 0) {
> +        checkFirstArg(newArg);
> +      }
> +      return super.setArg(index, newArg);
> +    }
> 
> Jeremy J Carroll
> Principal Architect
> Syapse, Inc.
> 
> 
> 
> On Oct 2, 2013, at 9:17 AM, Bryan Thompson <br...@sy...> wrote:
> 
>> Jeremy,
>> 
>> The link to the uncommitted code is no longer valid.  I am not quite sure
>> what you meant by defensive code in this instance.  As a general policy,
>> we do use asserts to catch things that should not be violated.  More
>> defensive code is used when the situation warrants it (more risk
>> associated with incorrect code or the code is particularly tricky or
>> problem prone). 
>> 
>> Bryan
>> 
>> On 10/1/13 6:11 PM, "Jeremy J Carroll" <jj...@sy...> wrote:
>> 
>>> 
>>> Hi 
>>> I have just committed straight forward fixes to:
>>> https://sourceforge.net/apps/trac/bigdata/ticket/737
>>> 
>>> (I do not believe review is needed, but review would never be unwelcome)
>>> 
>>> I did not commit the code that is found here:
>>> 
>>> https://github.com/jeremycarroll/bigdata/commit/c9dfa430d68c03c4246ebd5025
>>> 415d58cb1ce230
>>> 
>>> which is how I worked on the failing tests in
>>> com.bigdata.rdf.sail.TestNoExceptions
>>> which exercised the ClassCastExceptions in the defect report.
>>> (I have forgotten to include that test class in the test suite and will
>>> do so now)
>>> 
>>> These allowed me to find the root cause of the incorrect typing, and
>>> hence to fix it.
>>> 
>>> My question is:
>>> - is the preference to *not* include such defensive code in the main-line
>>> source,
>>> or
>>> - should I also commit this defensive coding
>>> 
>>> I have no particularly beef either way: I believe it to be a stylistic
>>> preference.
>>> 
>>> Jeremy J Carroll
>>> Principal Architect
>>> Syapse, Inc.
>>> 
>>> 
>>> 
>>> 
>>> --------------------------------------------------------------------------
>>> ----
>>> October Webinars: Code for Performance
>>> Free Intel webinars can help you accelerate application performance.
>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>>> from 
>>> the latest Intel processors and coprocessors. See abstracts and register >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktr
>>> k
>>> _______________________________________________
>>> Bigdata-developers mailing list
>>> Big...@li...
>>> https://lists.sourceforge.net/lists/listinfo/bigdata-developers
>> 
>