420chan now has a web-based IRC client available, right here
Leave these fields empty (spam trap):
Name
You can leave this blank to post anonymously, or you can create a Tripcode by using the float Name#Password
Comment
[*]Italic Text[/*]
[**]Bold Text[/**]
[~]Taimapedia Article[/~]
[%]Spoiler Text[/%]
>Highlight/Quote Text
[pre]Preformatted & Monospace text[/pre]
1. Numbered lists become ordered lists
* Bulleted lists become unordered lists
File

Sandwich


Community Updates

420chan now supports HTTPS! If you find any issues, you may report them in this thread
C++: TRY-CATCHING for Bounds by Nicholas Blacklock - Thu, 03 Aug 2017 20:40:54 EST ID:HsZblEoz No.37132 Ignore Report Quick Reply
File: 1501807254829.png -(32495B / 31.73KB, 500x386) Thumbnail displayed, click image for full size. 32495
Hay PROG!
With C++, I'm doing a lot of computation with arrays/vectors and always running into bounds/BAD_ACCESS errors. I'm here to ask if using try-catch blocks to handle these guaranteed thrown exceptions is a good idea.

You can find my code snippet at https://pastebin.com/uWM3MXxs
>>
Nicholas Blacklock - Thu, 03 Aug 2017 20:44:57 EST ID:HsZblEoz No.37133 Ignore Report Quick Reply
>>37132
I should explain my code. Down in line 8, the piece:
map[y1][x1-1]
Is the part that 's throwing the exception
>>
Charlotte Docklebury - Thu, 03 Aug 2017 22:30:35 EST ID:lVN/jRP+ No.37134 Ignore Report Quick Reply
There is such a thing as an unavoidable error, but this isn't it. You can catch and nothing bad will happen, but take some pride in your code.
>>
Clara Ponnerman - Fri, 04 Aug 2017 01:46:48 EST ID:P6PS9CBz No.37135 Ignore Report Quick Reply
Generally you should avoid using try/catch mechanics to catch programming errors that you have written yourself. In this case, have you validated that y1 and (x1 - 1) are both valid indices into your map? For example, have you considered that (x1 -1) might be a negative number in the case that x1 is 0?
>>
Matilda Boffingwater - Fri, 04 Aug 2017 08:41:34 EST ID:WLOo3E7i No.37136 Ignore Report Quick Reply
>>37132
Personally I think you should check for the bounds error instead of using an exception.

You could make your isIntIn function take in map, y1, and x1-1, and then do the bounds checking in there.
Or just do it in the if before you call your isIntIn function
>>
Hamilton Bassletone - Sun, 06 Aug 2017 19:23:41 EST ID:udAmwxZO No.37139 Ignore Report Quick Reply
Manual bounds checking: using an IF block (for bounds checking, aka "if (x<MAX_X){}") requires fewer machine instructions than a try..catch block. This is common practice
>>
Phineas Greenridge - Sun, 06 Aug 2017 19:41:12 EST ID:HsZblEoz No.37140 Ignore Report Quick Reply
>>37139
Ok thanks for the answers. I had tended to shy away from a bunch of nested bounds checking when I could just throw it all in a try-catch, but if it's faster then I'll follow common practice
>>
Shitting Tillinglock - Mon, 07 Aug 2017 19:16:16 EST ID:Kaw49/tj No.37141 Ignore Report Quick Reply
>>37140
The speed of try/catch is hard to think about. First you have to understand the compiler's implementation then have you have to consider what kind of memory penalty the catch is likely to entail. If it's not high performance code or the exceptions are truly exceptional, it's not worth thinking about it.
>>
Phoebe Chimblewell - Mon, 07 Aug 2017 23:38:55 EST ID:JneGddQE No.37142 Ignore Report Quick Reply
>>37141
well since you told me not to think about it, I wanna think about it now. Care to explain??
>>
Rebecca Crunderned - Tue, 08 Aug 2017 02:41:20 EST ID:P6PS9CBz No.37143 Ignore Report Quick Reply
Often times try-catch semantics are more expensive than a simple if-check. The reason for this is because of all the work that modern operating systems have to set up in order to make try-catch blocks work. When an exception is thrown, what tends to happen is that the processor's hardware exception interrupt vector is triggered (which punts you over to kernel-mode to handle it). When the interrupt vector determines that this is a software-initiated exception, it hands the exception off to the OS kernel to handle. Then when the OS kernel deems that this exception isn't one the special kernel software interrupts, it hands it off to the usermode program's exception handler. After all of that, your program goes into a special mode where it gets the chance to handle the exception or get force-exited by the OS. That's *a crapton* more work that the processor has to do versus a simple if-check.
>>
Jack Heshfield - Tue, 08 Aug 2017 18:32:03 EST ID:akqfogJa No.37144 Ignore Report Quick Reply
>>37143
That's not how exceptions are always handled. It's a different story for every implementation, but in general the catch can stand around looking dumb for a long time.
>>
Charles Gallylat - Thu, 24 Aug 2017 17:54:54 EST ID:9QSfnS0r No.37166 Ignore Report Quick Reply
>>37143
That may be true, but I doubt that modern compilers won't optimize exceptions you handle yourself to the point where there's practically no difference because 99% of the time you already know exactly which exceptions you want to catch in which order at compile time.
>>
Fanny Wondleson - Sat, 07 Oct 2017 16:29:47 EST ID:JfbkjUm/ No.37211 Ignore Report Quick Reply
>>37143
Yep.
But if you know that the exception will happen infrequently, and you have a lot of if's, then it's possible that all branch mispredictions you might get add up to an even greater penalty. As you say, unless it's performance critical it's not worth thinking about.
And if it is performance critical, the only way you'll know is by measuring.


Report Post
Reason
Note
Please be descriptive with report notes,
this helps staff resolve issues quicker.