1

Is it bad practice use try-catch like goto? For example, simple code

try{
    if(argc<2){
        std::cout<<"no inputfile"<<std::endl;
        throw 1;
    }
    STARTUPINFO cif;
    ZeroMemory(&cif,sizeof(STARTUPINFO));
    PROCESS_INFORMATION pi;
    if(FALSE==CreateProcess(argv[1],NULL,NULL,NULL,FALSE,NULL,NULL,NULL,
                            &cif,&pi)){
        printf("smth is wrong");
        throw 1;
    }
    WaitForSingleObject(pi.hProcess, INFINITE);
    GetExitCodeProcess(pi.hProcess, &exitCode);
    std::cout<<"Process return"<<exitCode<<std::endl;
    throw 1;
}
catch(int a){
    printf("press Enter");
    getchar();
}
none
  • 10,753
  • 9
  • 46
  • 81
Alexey Matveev
  • 459
  • 1
  • 4
  • 13
  • 1
    possible duplicate of [Using exceptions for flow control](http://stackoverflow.com/questions/9306913/using-exceptions-for-flow-control) – Andrey Oct 26 '12 at 12:01
  • 3
    It is usually not a good idea to use `goto`, but when you want to use `goto`, camouflaging it as exception handling actually makes it worse. – Magnus Hoff Oct 26 '12 at 12:03
  • See also [Why not use exceptions as regular flow of control?](http://stackoverflow.com/questions/729379/why-not-use-exceptions-as-regular-flow-of-control) – Andrey Oct 26 '12 at 12:03
  • 1
    In this case, if you're looking to "disguise a goto" then `do { ... break; ... } while(false);` is marginally better than `try { ... throw ... throw } catch() {}`. A try block that you *always* exit by throwing runs against the intention. Moving the contents of the `try` block into a function and using `return` to exit early is probably better, and would be enough of a disguise to fool *most* people. The only ones who'd still catch you out are the ones who say a function must only have one `return` statement. – Steve Jessop Oct 26 '12 at 13:46

2 Answers2

5

If you're asking whether it's wrong to use exceptions for program flow, the answer is yes, it's wrong.

That said, for cases where you don't care about performance too much, you can get away with it as long as you don't tell anyone on the internet, and as long as you don't have a production requirement or a long-term maintenance requirement.

In this instance you appear to be using exceptions correctly for everything except the final, successful case.

Lightness Races in Orbit
  • 358,771
  • 68
  • 593
  • 989
  • 3
    -1 because you're wrong, but as an aside, if you felt this question was non constructive enough to close it, then why did you answer it? – John Dibling Oct 26 '12 at 13:15
  • @JohnDibling: Please indicate which part of my answer you disagree with. – Lightness Races in Orbit Oct 26 '12 at 13:34
  • I can't think of anything to use exceptions for *other than* program flow. `try/catch` is a control flow structure. The eternal debate is, what conditions are considered "exceptional enough" to warrant using it. – Steve Jessop Oct 26 '12 at 13:44
  • @LightnessRacesinOrbit: I disagree with the sweeping generalization that: "it's wrong [to use exceptions for program flow]". – John Dibling Oct 26 '12 at 13:53
  • +1 The "eternal debate" has been settled long time ago: exceptions are for exceptional situations. – Sergey Kalinichenko Oct 26 '12 at 14:05
  • @JohnDibling: How is it a "sweeping generalisation" when I spent the entire next paragraph qualifying it? – Lightness Races in Orbit Oct 26 '12 at 14:20
  • Your next paragraph effectively reinforced the first sentence, by casting the idea of exceptions-as-program-flow in such a light so as to suggest that only a non-thinking dolt would use such a construct in real code. It's a false qualification. – John Dibling Oct 26 '12 at 14:29
  • @JohnDibling: That's your inference, not the implication. I listed concrete examples of when I'd feel free to use such a "pattern" if I felt inclined to (though I should emphasise that this has never occurred in my lifetime). I never used the word "dolt" -- you did. – Lightness Races in Orbit Oct 26 '12 at 14:34
1

In general (as in, in a language-agnostic sense, across the board) it is bad practice to use the try / catch mechanism as a control flow management aid. Use it as intended, for managing exceptions. Use control flow constructs to control flow.

Grant Thomas
  • 42,191
  • 8
  • 81
  • 120