Leave these fields empty (spam trap):
You can leave this blank to post anonymously, or you can create a Tripcode by using the format Name#Password
[i]Italic Text[/i]
[b]Bold Text[/b]
[spoiler]Spoiler Text[/spoiler]
>Highlight/Quote Text
[pre]Preformatted & Monospace Text[/pre]
[super]Superset Text[/super]
[sub]Subset Text[/sub]
1. Numbered lists become ordered lists
* Bulleted lists become unordered lists


C++: TRY-CATCHING for Bounds

- Thu, 03 Aug 2017 20:40:54 EST HsZblEoz No.37132
File: 1501807254829.png -(32495B / 31.73KB, 500x386) Thumbnail displayed, click image for full size. C++: TRY-CATCHING for Bounds
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 HsZblEoz No.37133 Reply
I should explain my code. Down in line 8, the piece:
Is the part that 's throwing the exception
Charlotte Docklebury - Thu, 03 Aug 2017 22:30:35 EST lVN/jRP+ No.37134 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 P6PS9CBz No.37135 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 WLOo3E7i No.37136 Reply
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 udAmwxZO No.37139 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 HsZblEoz No.37140 Reply
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 Kaw49/tj No.37141 Reply
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 JneGddQE No.37142 Reply
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 P6PS9CBz No.37143 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 akqfogJa No.37144 Reply
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 9QSfnS0r No.37166 Reply
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 JfbkjUm/ No.37211 Reply
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
Please be descriptive with report notes,
this helps staff resolve issues quicker.