empty catch block

[kamisama]

I've read that empty catch blocks are bad practice, but I have recently encountered a problem where one makes perfect sense. Since I am a beginner, I take this to mean there is a better solution to my problem.

I'm writing a routine to solve sudoku puzzles. This involves two algorithms: the first, simple_solve, which performs a variety of standard techniques to deduce the solution. (This alone works for easy to medium difficulty sudokus.) The second, guess_solve, which I am currently writing, involves making a guess and then running simple_solve to see if it works.

My goal here is to write the full solver on my own before I look at how other people do it, so please don't advise me on how to write sudoku solvers.

Here is the code snippet I wish to write next. (I hope my class and member functions are obvious from their names.)

int guess_solve(Sudoku& sudoku)
{
    sudoku.simple_solve();

    if(sudoku.solved())     // If simple solve works exit function.
        return 0;                   

    for([iterate over unsolved boxes b])
    {
       for([iterate over possible numbers i])
       {
           Sudoku s = sudoku;
           s.guess(b,i);
           try{
               s.simple_solve();  // Simple solve throws if any box ends up 
                                  //  with zero possibilities for its entry.
               if(s.solved())     // If simple solve works exit function.
               {
                   sudoku=s;
                   return 0;
               }
               else               // If it gets stuck (but DOES NOT encounter
                                  //  an inconsistency) use recursion.
               {
                   guess_solve(s);
                   sudoku=s;
                   return 0;
               }
            }
            catch(...)            // If our guess is wrong, simply move on
                                  //  and try the next guess.
            {
            }
        }
     }
}

I'm mainly interested in the usage of try/catch in this context rather than any minor mistakes (I haven't tested this yet).

Is this bad practice, and why?

Thanks.

[Moschops]

Is this bad practice, and why?

It is bad practice. You're using exceptions to handle correct behaviour. You should code so that s.simple_solve(); returns some value indicating success or failure, and handle it appropriately. Throwing an exception because you are too lazy to handle expected cases is bad practice.

[kamisama]

Many thanks, Moschops. I see what you mean.

I should return a bool indicating success/failure. In the case of s.guess_solve(); itself, there are three outcomes however, 'success', 'failure', and 'stalemate'. What is the usual coding practice for indicating more than two success-related outcomes? Clearly returning integers will work, but is it better practice to return something like an enum or string which might be more informative to other people reading the code?

[webJose]

One valid case I can think of right now is in destructor code. More often than not you'll want your destruction to go unnoticed and you therefore use an empty catch. But of course it all depends on what you do in the destructor and the tools you use. If you are using a library that throws exceptions, you might want to protect your destructor with the catch block, but it may not even be necessary if no code inside it throws anything.