Thread: Multidimensional Array Niggles!!!

Originally Posted by tabstop

What extra security measures are these? Either you ran a test that exposed the error, in which case you can debug (if you chose debug) or you can maybe debug (if you chose exceptions); or you didn't run a test that exposed the error, in which case debug vs. exceptions don't matter.

It does matter, because it stops undefined behavior in case you miss it!

Exceptions for user errors?!

What does that mean?

I mean, come on, it's such a simple change. Change index operator to at(). You shouldn't be using C-style arrays anyway, since we have std::array, and yes, it has at().

Originally Posted by Elysia

It does matter, because it stops undefined behavior in case you miss it!

I'm sure you're talking about this particular bit of undefined behavior.

Originally Posted by Elysia

I mean, come on, it's such a simple change. Change index operator to at(). You shouldn't be using C-style arrays anyway, since we have std::array, and yes, it has at().

You'd like it to be that simple. Of course, I feel like I haven't talked with you at all since you're comfortable with this sort of post, still. I think recently you should have read reasons why exceptions aren't as easy or as reasonable for debugging as you say they are.

To your point about why we can't catching exceptions, I misspoke. I meant a no-throw guarantee not the strong one. Even so, I directly asked what if the code shouldn't throw exceptions, which you didn't answer as if I was making something up. But really to me the no-throw guarantee existing makes me shun exceptions as a debugging tool. I mean, I'd rather meet my exception safety guarantee than break it to "prevent undefined behavior."

ETA: This also bugged me a lot:

OK, to be honest, if you have catch blocks, it might be a little harder to catch the problems, but debuggers can be configured and code can be disabled.

Who cares. As far as I know that has nothing to do with fixing bugs in released code, which I think is your primary reason for liking exceptions so much. Presumably, (you brought this up as an argument but) there is some code path you haven't tested and you want to "disable code" to help you discover errors. Does not compute.

Danger Will Robinson, danger!

Originally Posted by whiteflags

You'd like it to be that simple. Of course, I feel like I haven't talked with you at all since you're comfortable with this sort of post, still. I think recently you should have read reasons why exceptions aren't as easy or as reasonable for debugging as you say they are.

Nothing that has changed my mind so far.

To your point about why we can't catching exceptions, I misspoke. I meant a no-throw guarantee not the strong one. Even so, I directly asked what if the code shouldn't throw exceptions, which you didn't answer as if I was making something up. But really to me the no-throw guarantee existing makes me shun exceptions as a debugging tool. I mean, I'd rather meet my exception safety guarantee than break it to "prevent undefined behavior."

I couldn't answer it because it made no sense.
But I agree that I would meet exception safety than break it to prevent undefined behavior.
However, that just means that the function needs to eat any exceptions it throws. So using at() is still fine so long as you don't let it propagate.
If the function must be able to throw exception such as those from at(), then your design is broken if the function has a no-throw guarantee.

Who cares. As far as I know that has nothing to do with fixing bugs in released code, which I think is your primary reason for liking exceptions so much. Presumably, (you brought this up as an argument but) there is some code path you haven't tested and you want to "disable code" to help you discover errors. Does not compute.

But it is also a tool for finding out-of-bounds access more easily, too, since an out-of-bound index can easily be a memory location where another variable is located, which could mean a lot of false positives if you try to monitor for writes/reads there.
But it does not mean you can be lazy with your testing and debugging because you have safeguards in place. You should always properly test your code as much as you can.

You can disable the catch block for the exceptions at() throws, then your debugger will catch the exception, all the time.
Or you can configure your debugger to catch them no matter what.
Problem solved.