Throw an exception VS Return an error in an attempt to catch, finally

Question

I'm sure I already know the answer, but I'm still curious about the opinion of error handling in the Try, Catch, finally block, but when you repeat yourself.

BTW - I'm not talking about User Input - but using this as an example, because it's clear and short

Consider this bit of code ...

try { if (success) { return someSuccessMessage; } else { logError("User input not correct format"); return someErrorMessage; // repeats itself } } catch (Exception ex) { logError(ex.Message); return someErrorMessage; // repeats itself } 

Let's say we have a function that, if it fails, we want to return an error message, because the exception does not matter - our function failed, and the user does not need any additional details.

I have always believed that if you handle the error, avoid the exception - as this is not exceptional, but I wondered how to avoid repeating myself ... You could do the following to avoid repeating ...

 try { if (success) { return someSuccessMessage; } else { throw new Exception("User input not correct format"); } } catch (Exception ex) { logError(ex.Message); return someErrorMessage; } 

This is not a good example, but I am going to make brevity for code repetition.

It is known that due to performance limitations, errors occur, but what are the thoughts about this situation?

Answer 1

I ask a question about sharing issues here. If this function is not part of the user interface, it should not deal with error messages. Instead, exceptions should be thrown. The caller of this method, if it is part of the user interface, may want to create an error message to display. If the caller was a web service, he would like to create a SOAP Fault that might not use the same message (if he used any message at all).

I also highly recommend you log ex.ToString (), not ex.Message.

Answer 2

IMO, an exception should only be thrown when it goes beyond the scope of the situation to be fixed. The user entering the wrong format is known and should not throw an exception.

Treat the Exception as catastrophic (data center in case of fire, earthquake, etc.). Thus, you will see the difference between handling "regular errors" and "Exceptions."

And yes, throw and catch. An exception is a lot of performance; it is best to avoid them.

Answer 3

In your case, I just return the error message (first example), because throwing an exception just to catch it 3 lines below seems a bit strange.

The completely different thing is that I usually avoid returning error codes whenever possible - when I get an error, I am through an exception and I will catch it at the highest level. Thus, the code is not clogged with error handling all over the world, and it is much easier to see the business logic. In your case (if you control it, of course), a method that returns success could throw an exception if it fails, and you would not have to ask this question at all :)

It is true that Exceptions are expensive in C #, so they should not be abused. Having said that when you have an error, 50 ms or so fall into performance, as a rule, they do not matter, so I try to use them to keep the code clean.

Answer 4

I would agree with your logic in your example, however, what exception do you think you are handling in the exception handling block against your program test? I suspect your exception handling unit is really “in case something happens.” So it really comes down to an exception handling rule.

If you do not need to handle the exception, and do not handle it at a separate architectural boundary. If it is on the edge of the component border, you can wrap it by placing the original in an internal exception.

If the functionality was called from code, you would either want to check the result with some representation of the state as an answer (HRESULT is a prime example of this. 0 == SUCCESS,! = 0 == failure) or use exceptions.

Testing for software errors or component failures is where you will use exceptions, if you are checking for user input in the user interface, you can simply use logical and return status codes to report an error to the user.

Finally think about localization. If you are pulsing an error message in English through the system and presenting it to your French-speaking user, that will not be useful, and you do not want to start parsing strings in the user interface to create the French version, so exceptions are a way as long as useful The exception load has enough information to create a useful error message for the user to take corrective actions.

Use a status code, where you have a tight connection between components and the calling component, know what to do in different state states.

BTW You might want to write a stack trace, as well as just a message using ToString (), as it will give you more useful information to solve the problem.

NTN

Answer 5

Extract duplicate code into a function if you feel that repeating yourself is a problem.

 error_code_t fail (string message) { logError(message); return someErrorMessage; } // ... try { if (success) { return someSuccessMessage; } else { return fail("User input not correct format"); } } catch (Exception ex) { return fail(ex.Message); } 

To be honest, I wouldn’t worry about duplicating a couple of lines in the same function.

Answer 6

In this case, I would say that try / catch is not needed, since your if more than adequately handles your error.

but the bottom one is a beleive style that should be used for more complex situations.