Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>My rule of thumb is:</p> <ul> <li>If you can do anything to recover from an error, catch exceptions</li> <li>If the error is a very common one (eg. user tried to log in with the wrong password), use returnvalues</li> <li>If you can't do anything to recover from an error, leave it uncaught (Or catch it in your main-catcher to do some semi-graceful shutdown of the application)</li> </ul> <p>The problem I see with exceptions is from a purely syntax point of view (I'm pretty sure the perfomance overhead is minimal). I don't like try-blocks all over the place.</p> <p>Take this example:</p> <pre><code>try { DoSomeMethod(); //Can throw Exception1 DoSomeOtherMethod(); //Can throw Exception1 and Exception2 } catch(Exception1) { //Okay something messed up, but is it SomeMethod or SomeOtherMethod? } </code></pre> <p>.. Another example could be when you need to assign something to a handle using a factory, and that factory could throw an exception:</p> <pre><code>Class1 myInstance; try { myInstance = Class1Factory.Build(); } catch(SomeException) { // Couldn't instantiate class, do something else.. } myInstance.BestMethodEver(); // Will throw a compile-time error, saying that myInstance is uninitalized, which it potentially is.. :( </code></pre> <p>Soo, personally, I think you should keep exceptions for rare error-conditions (out of memory etc.) and use returnvalues (valueclasses, structs or enums) to do your error checking instead.</p> <p>Hope I understood your question correct :)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload