# Runtime errors vs. logic errors

**URL:** <https://www.ruby-forum.com/t/runtime-errors-vs-logic-errors/218917>\
**Category:** GNU Radio\
**Created:** [April 16, 2012, 3:02am UTC](https://www.ruby-forum.com/t/runtime-errors-vs-logic-errors/218917 "2012-04-16T03:02:21Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\
**Post date:** [April 16, 2012, 3:02am UTC](https://www.ruby-forum.com/t/runtime-errors-vs-logic-errors/218917/1 "2012-04-16T03:02:21Z")

</div>

Kind of a nitpicky C++ thing, but shouldn’t argument checks on the  
access code in gr\_correlate\_access\_code\_tag\_bb.cc throw  
std::invalid\_argument or std::range\_error, which are both derived from  
std::runtime\_error, versus std::out\_of\_range, which is derived from  
std::logic\_error? My understanding is that the latter is used for cases  
such as referencing index 11 in a string that was declared to have  
length 10, etc, whereas the former are used for checking user-supplied  
parameters. A quick " find. | xargs grep out\_of\_range" yields the  
attached output. It looks like the uses in  
/src/lib/swig/guile/std\_vector.i are correctly used (popping from an  
empty vector, referencing an out-of-bounds index, etc.) but the other  
cases should be invalid\_argument. Thoughts? If this gets the go-ahead,  
I’ll make a patch sometime this week.

Thanks,  
Sean

---

<div class="post-metadata">

**Author:** ![NowlanS\_Sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f05b48/32.png) [@NowlanS\_Sean](https://www.ruby-forum.com/u/NowlanS_Sean)\
**Post date:** [April 16, 2012, 3:03am UTC](https://www.ruby-forum.com/t/runtime-errors-vs-logic-errors/218917/2 "2012-04-16T03:03:36Z")

</div>

Sorry for the re-post; forgot to include the attachment.

From: discuss-gnuradio-bounces+sean.nowlan=removed\_email\_address@domain.invalid  
[[mailto:discuss-gnuradio-bounces+sean.nowlan=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+sean.nowlan=removed_email_address@domain.invalid)] On  
Behalf Of Nowlan, Sean  
Sent: Sunday, April 15, 2012 9:01 PM  
To: removed\_email\_address@domain.invalid  
Subject: [Discuss-gnuradio] runtime errors vs. logic errors

Kind of a nitpicky C++ thing, but shouldn’t argument checks on the  
access code in gr\_correlate\_access\_code\_tag\_bb.cc throw  
std::invalid\_argument or std::range\_error, which are both derived from  
std::runtime\_error, versus std::out\_of\_range, which is derived from  
std::logic\_error? My understanding is that the latter is used for cases  
such as referencing index 11 in a string that was declared to have  
length 10, etc, whereas the former are used for checking user-supplied  
parameters. A quick " find. | xargs grep out\_of\_range" yields the  
attached output. It looks like the uses in  
/src/lib/swig/guile/std\_vector.i are correctly used (popping from an  
empty vector, referencing an out-of-bounds index, etc.) but the other  
cases should be invalid\_argument. Thoughts? If this gets the go-ahead,  
I’ll make a patch sometime this week.

Thanks,  
Sean

---

<div class="post-metadata">

**Author:** ![NowlanS\_Sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f05b48/32.png) [@NowlanS\_Sean](https://www.ruby-forum.com/u/NowlanS_Sean)\
**Post date:** [April 19, 2012, 4:23pm UTC](https://www.ruby-forum.com/t/runtime-errors-vs-logic-errors/218917/3 "2012-04-19T16:23:46Z")

</div>

On Sun, Apr 15, 2012 at 9:02 PM, Nowlan, Sean  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> /src/lib/swig/guile/std\_vector.i are correctly used (popping from an empty  
> vector, referencing an out-of-bounds index, etc.) but the other cases should  
> be invalid\_argument. Thoughts? If this gets the go-ahead, Ill make a patch  
> sometime this week.
> 
> Thanks,
> 
> Sean

Sean,  
Sure, this makes sense. You’re right that it’s a bit nit-picky, but  
you’re technically correct, and we might as well attempt to be as  
correct as possible whenever we can. We’ll wait for your patch, but  
probably apply it off of the master HEAD branch to go into 3.6.1.

Thanks,  
Tom
