not all paths return a value

  • Thread starter Thread starter Guest
  • Start date Start date
---snip---
I've read a few of these answers that state something along the lines of:


That should never be required. Since False is the default return value for
any boolean function/variable/whatever, explicitly setting the return =
False should never be required. If it is suddenly required after 30 years of
Click to expand...
---snip---

Yes, I know. As I said in another post, I misread the original post.

Sorry.

/JB
 
Joergen Bech @ post1.tele.dk> said:
Care to give me an example that involves On Error Goto?
Click to expand...

My bad. I finally didn't test it with 'On Error GoTo'.
But when the "On Error ..." abomination is used, as in the sample
the original poster provided ...

Check the samples below. None of them produce squiggly lines, even
though I am fairly positive that they cover both objects and value
types as return values. I see no difference in behavior due to
the choice of return types.
Click to expand...

I believe the warning should at least be shown for those samples involving
reference types, regardless of whether or not they contain 'On Error GoTo'.
Interestingly the warning is shown for this snippet:

\\\
Public Function Foo() As Object
GoTo BailOut
Return 2
BailOut:
End Function
///
If you look at what the compiler turns the samples into, you will
see that something is explicitly returned on all code paths in all
samples.
Click to expand...

In VB its granted that any function always returns a value on all code path,
but this is not necessarily done explicitly in the source code. So I don't
think that the decision whether or not to show the warning should be based
on the actual IL the compiler emits.
 
see that something is explicitly returned on all code paths in all
In VB its granted that any function always returns a value on all code path,
but this is not necessarily done explicitly in the source code. So I don't
think that the decision whether or not to show the warning should be based
on the actual IL the compiler emits.
Click to expand...

(last comment for tonight)

ok. I understand what you want.

But "On Error ..." is an abstraction that is turned into
something completely different (and much bigger).

I think what you are asking for would be extremely difficult
to implement - possibly basing the squiggly lines on something
different than what is being used by IntelliSense.

I am not qualified to speculate on how the
parser/compiler/IntelliSense
work their magic, so I'll leave this one alone.

/Joergen Bech
 
Herfried, totally agree with your comments, i suppose what i was getting at
is that if you start relying on the warning you can be misled into thinking
you are returning a value when you are not exlpicitly doing it. i know
specifying a value type as the return value will always return a value, hut i
would have expected the warning when there is a code path that does not
***explicitly*** return a value.
seems to me this an 'intermittent' warning and can be misleading.

thanks guy

Herfried K. Wagner said:
Ken,

Ken Halter said:
I've read a few of these answers that state something along the lines of:


That should never be required. Since False is the default return value for
any boolean function/variable/whatever, explicitly setting the return =
False should never be required. If it is suddenly required after 30 years
of programming, there should be a huge notice posted on the web somewhere
that says "forget about your existing source code, everything has suddenly
changed for no good reason"
Click to expand...

You could actually disable the warning. Simply open up the project file in
a text editor and add the warning number (42105) to the 'NoWarn' element.
My main concern is that the warning only occurs at functions which return a
reference type.

The full text of the warning makes this more clear: "[...] A null reference
exception could occur at run time when the result is used". I do not think
that implicitly returning 'Nothing' is a big problem. The main problem is
IMO forgetting to set a return value for a certain code path inside the
function. The same problem applies to BC42104 too. I have summed up my
thoughts on the usefulness of this warning in an article (in German):

Zur Sinnhaftigkeit der Compilerwarnung BC42104
<URL:http://dotnet.mvps.org/dotnet/articles/bc42104/>
Click to expand...
 
Back
Top