Click here to Skip to main content
15,174,296 members
Please Sign up or sign in to vote.
2.23/5 (4 votes)
See more:
Suppose I check on an index being found and suppose, if the index is not found I throw an exception, will the method or function return something? In VB.NET code this would be:

VB
Function IdLikeToKnow() As Boolean
	Dim indexFound As Boolean = False
	If indexFound Then
		Return True
	Else
		Throw New IndexOutOfRangeException
		'Is the below statement evaluated??????
		Return False
	End If
End Function


Anybody has an idea? It is not a very urgent question, but I would like to know...
Regards and thanks in advance...
Posted
Comments
CHill60 20-Jan-16 3:30am
   
There is a lot to be said for empirical evidence - in other words, why didn't you just run this code to find out for yourself?
veen_rp 20-Jan-16 3:44am
   
Thanks CHill60, good point! I love empirical evidence; it was just a question which stayed in the back of my mind :). Thanks to all commentators. I think my question is answered and closed. For some of you: friendliness costs nothing...
CHill60 20-Jan-16 4:52am
   
Interesting that you have chosen Solution 1 as the accepted solution - it is unformatted code that doesn't really explain the situation and contains a link that also doesn't answer your question. Of the solutions posted Solution 5 is probably the best. I'm surprised no-one pointed you towards this article Exception Handling Best Practices in .NET[^]
veen_rp 20-Jan-16 8:45am
   
Thanks for the answer. Man, I'll think twice before posting another questions. To me it was just a bit of a mental exercise. Nothing ado with abuse and all the rest I got accused of. Didn't expect such hotheads... I should have sticked to your empirical solution in the first place :)
Anyways I'm enjoying the day very much in sunny Holland at the moment. Hope the same for you

So far, you did not get a satisfactory answer. What you got so far can only mislead you.

In brief, not only nothing will be returned, but you don't need to return anything in case of exception. Throwing exception may or may not be used in your case, but catching it locally would be a worst advice. Say, you have two possible results: true or false; then you should always return one or another. But you may need 3 results: true, false and "calling this function with these conditions makes no sense". Then, in last case, you can throw an exception and catch exceptions somewhere up the stack, then you will get the effect as if the function was not even called. Structured exception mechanism is similar to "time machine".

Perhaps my past answers can help you:
Does Exception in C# Constructor Cause Caller Assignment to Fail?[^],
where was stored .net exceptions in operating system[^].

—SA
   
Comments
veen_rp 20-Jan-16 11:26am
   
Sergey, thanks for your links. I had now time to look at them. It is clear to me now. In my code in the original question, if I comment out the 'Return False' line, indeed the compiler doesn't complain that 'a result is not returned on all code paths', which proves your point. The local catching of an exception was never part of my question. Indeed, best seems to catch exceptions 'as high' as possible or as generically as possible. Which is not always easy to do. I have withdrawn my solution selected, although to me the answer was straightforward and clear to me. I didn't realize selecting a solution would cascade like this. It was my first question on this forum. Hopefully not my last, if I can find the courage :). Rgds.
Sergey Alexandrovich Kryukov 20-Jan-16 11:49am
   
You are welcome.

About the compiler complain: a compiler should "see" that each instruction flow (for non-void method, a function) always leads to either return or throw. That is, throw without any return at all is a valid case. It's the best not to handle exceptions locally, except few special cases. Then the execution jumps "back" to the point where you function is not event called (not counting side effects) of the call. That means, you still need to catch all exceptions, at each once per each thread, but these catch points should be placed strategically. Only few of them may handle special cases, which is also can be a good strategy, but only in certain special cases. There is a heated discussion where exception handling should be used to express non-error logic of the application; I personally think that it is acceptable. Main approach to exception is: throw and forget. Your application logic should be adopted to that. Please see my other comments to Solution 2. You still need to catch all exceptions in all cases, but just because each thread should have at least one "catch all" point somewhere closer to the very top stack frame.

Oh, yes, local catching wasn't a part of your question. I mention it because 1) it's a part of wrong answers you got; 2) this is a typical mistake. In other words: I appreciate your approach shown in your question; it looks more reasonable then those answers.

Did I answer your question? To the essence of this question: 1) function can ends with throw, and it makes sense and is acceptable, 2) in this case, nothing is returned, 3) moreover, in this case, your execution jumps to the point where your function wasn't even called.

—SA
veen_rp 20-Jan-16 14:23pm
   
Yep, you answered just fine. I'm an old programmer who used to program C on unix (yes, with those difficult *pointers); no catching exceptions then, only returning -1, 0 or 1 and ocasionally an exotic 3... I'm happy .Net is around, it is exciting. In any case I should have followed the advise of CHill60 and just test it out myself empirically; it is not rocket science. Thanks for your links again, they are worth reading it. Is there a button I can press to close the question as solved?
Sergey Alexandrovich Kryukov 20-Jan-16 16:33pm
   
You are very welcome.
There is no such action as closing the question. The questions are closed when they are inappropriate in some way.
There is a button to accept one or more answers formally.
—SA
This code is ugly. If index is not found your application will crash.
There will be nothing returned and the application will crash unless you handle the error in the code that calls this function.

Fact of matter - Even if you do handle the error in the parent method, you will still not get anything returned (not from this method).

To return something use try-catch within this method.
   
Comments
   
Abhinav,
Sorry, but this is the worst possible advice. I have only one explanation: you have no idea how structured exception mechanism works and hence badly misuse it. Your advice means that you handle exceptions locally. This would be a great abuse. Not returning anything is one of the purposes of exceptions. Another purpose is handling exceptions very rarely, compared to the number of points where an exception can be thrown. You isolate handling from "normal" execution flow by handling many possible exceptions in one or very few places. Exceptions do propagate; and, if you catch it somewhere up the stack, you handle many different cases. As to the returned value, the effect is the same as not calling the function at all.
—SA
Abhinav S 20-Jan-16 3:42am
   
Sorry SA, I'm not sure what provokes you to start this discussion (if you have read my answer at all - or for that matter the question itself)
1) No advice is shared with the poster of this question. Only an answer to his query is provided.
2) Handling errors (or debating about try-catch) is a totally different topic of discussion and it would not be right to discuss it as a part of this question.
3) There CAN be return statements inside the catch block. In many places, adding a return inside catch is considered good coding practice. The one con with this approach is readability of code and so this depends on the individual.
I would also suggest you look at the compiled code in both cases where you will notice that both approaches (having return inside catch or outside the try catch) generate the same code.
Sergey Alexandrovich Kryukov 20-Jan-16 11:25am
   
The matter is quite important; one of the central aspects of programming.

1) your advice is your last statement. "use" can be understood as the advice, nothing else.
2) it's not a different topic; when you give bad advice, nothing like "different topic" can be an excuse.
3) yes, it can be, so what? look at the practical example: I don't know if it makes sense, but, formally, there are 3 cases (not 2!): 1) index found, 2) index not found, 3) index out of range. Formally, they are 3 different case. If you say that the result is of the type boolean? and advised to return true, false and null, I would understand it. But you want to use local exception handling to merge "not found" with "out of range". Maybe, semantically this is the same, but formally it is not. Therefore, not handling exception locally would make sense. Even if you understand how to do things correctly, your post would be still misleading.

Look, it's not a pleasure to discuss all that and correct you, believe me. I'm trying to help and avoid misleading. This is a really serious topic and really bad problem.

—SA
Abhinav S 20-Jan-16 3:50am
   
In addition, irrespective of whether the caller method is interested in the return or not, if the error is handled, the method does return.
Move the return inside the try part of your code and the compiler will complain that the catch does not have a return statement.
Sergey Alexandrovich Kryukov 20-Jan-16 11:26am
   
Wost thing is to even have try part too locally. I am not sure: do you understand that, without a catch, the method with raised exception will never return? Or do you think it returns somehow anyway?
Do you understand that structured exception mechanism works on top of usual stack operation set (calls and returns)? I'm asking because I'm not sure...
—SA
Abhinav S 20-Jan-16 11:35am
   
Please see my fist comment in the answer. The application will crash so there is no question of returning anything.
Sergey Alexandrovich Kryukov 20-Jan-16 11:37am
   
Again, wrong. Why the application would crash?
—SA
Sergey Alexandrovich Kryukov 20-Jan-16 11:52am
   
See also my comment to the inquirer's comment to the solution 5.
Abhinav, we can discuss something if you make it clear what you think on the questions I asked above.
From your words, I don't know if you understand exception propagation or not.
—SA
Abhinav S 20-Jan-16 12:14pm
   
Thanks SA (for your options) but I understand exception handling quite well and would not want to have a discussion on it. :)
Sergey Alexandrovich Kryukov 20-Jan-16 12:28pm
   
Good. I only want to make things clear, because they are very important.
—SA
Nope when there is a throw statement , it gets out of the loop and checks for any catch block, i wont execute the statements after throw,

The statements inside the catch block will be executed

Try
{
throw new bla bla;
line after throw-- this ll not be executed
}
catch
{
// the statemens inside this will be executed
}


[^]
   
Comments
   
Bad idea, very bad. You suggest to catch exceptions locally. Please see my comment to solution 2.
—SA
If once exception thrown execution will be stops(Next statements will not execute) from the current execution flow and executes corresponding catch block. This will stops the execution of application.

If you want to stop the execution on particular condition then throw exception.

If you don't want to stop application then return some value.If return statement encounters then controller will return to the caller function. next statements after return statement in the method will not execute.

Simple answer for your question is

After throw return will not executes.
   
v2
Comments
CHill60 20-Jan-16 3:28am
   
I think the OP was only throwing an exception in this proof-of-concept code to mimic what would happen if "real" processing threw an exception
Sri Nivas (Vasu) 20-Jan-16 4:35am
   
If only exception throws, then execution will halts. I don't think stopping application on some condition is not good idea. So return some value with out exception throwing will be good.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)




CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900