Its hard to give another approach given how abstract the code samples are, but as braindigitalis say if you are searching for something change the storage to something more suitable to perform a lookup. Also have others have said create a function that does the scan and returns the result so the return does the break.

From you sample this is faster to do the same lol

int i = 2;

int j = 0;

Ignore the try/catch exception route as it carries costs that make it perform worse than the other solutions presented.

If you've got two for loops you're looking at O(n*n) execution times.

I'd be tempted to refactor the code and eliminate the for loops if possible but that's just me...

In all seriousness, I'd be interested to see that.

for(int i = 0; i < 100; ++i)
{
    if(((i / 10) - 1) == ((i % 10) + 1))
        break;
}

This is apparently common in Python (not just for breaking out of inner loops - iterators throw an exception when they reach the end of the container!), but in C++ I wouldn't recommend this. Even in Python I'm leery of doing this, since as ferrous points out exceptions are supposed to be for exceptional cases meaning abusing exceptions like this dilutes their meaning.

Python exceptions are not meant to represent exceptional error conditions alone, so it isn't an "abuse." As you point out, sequence iteration is terminated by raising StopIteration. This kind and level of exception usage is key to Python's dynamic, introspective nature.

As to the OP's question about breaking out of nested loops, assuming the code can not be refactored into a function a pair of adjacent linear iterations, and your language does not have labeled breaks, just use a goto.

(Amusingly, this very topic was covered in this very forum as far back as 2006, with the same conclusions drawn. The more things change…)

If you've got two for loops you're looking at O(n*n) execution times.

I'd be tempted to refactor the code and eliminate the for loops if possible but that's just me...

In all seriousness, I'd be interested to see that.

for(int i = 0; i < 100; ++i)
{
    if(((i / 10) - 1) == ((i % 10) + 1))
        break;
}

at least 1 is gone and we only need a normal break

And suddenly the code is more complicated and about 10-100x slower, because the divisions are taking many more cycles than the other simple operations.

Look ma! no breaks!

int i, j;

for(i = 0; i < 2; i++) {
    for(j = 0; j < 10; j++) {
        // if(i - 1 == j + 1) <- will be true for i==2 and j==0
    }
}

seriously though, how often will you have a situation where you need a nested loop and break out on an arbitrary condition and continue work after the loop?

Smells to me like a violation of SRP.

Some possible solutions depending on the actual algorithm:

Factor out the loop into another function and just return instead of breaking

or calculate the terminating condition beforehand and adjust the loop boundaries

or collect the affected elements and iterate over all of them

Awesome approach. But then again, it's setting up a lambda object (with captures and all) for no good reason. The compiler might optimize that out again, but that isn't granted.
Similar is true for any such construct involving function calls of which you can assume but don't know for sure that the compiler will optimize them away.

Python exceptions are not meant to represent exceptional error conditions alone, so it isn't an "abuse." As you point out, sequence iteration is terminated by raising StopIteration. This kind and level of exception usage is key to Python's dynamic, introspective nature.