return null upon exception?

  • Thread starter Thread starter Daniel Billingsley
  • Start date Start date
D

Daniel Billingsley

Suppose I have a method that returns some type of object, and in that method
I have a try...catch block and just throw my own exception when I catch one.
The compiler insists that all code paths return a value, so...

do I just put
return null;
after I throw my exception in the catch block?

or should I initialize the local variable to null and return it in a finally
block?

or something else entirely, or is it just personal taste?

Thanks.
 
Suppose I have a method that returns some type of object, and in that
method I have a try...catch block and just throw my own exception when
I catch one. The compiler insists that all code paths return a value,
so...

do I just put
return null;
after I throw my exception in the catch block?

or should I initialize the local variable to null and return it in a
finally block?

or something else entirely, or is it just personal taste?
Click to expand...

As you say, its pretty much personal taste...

No matter how you do it, the most important thing is to document the
function so that the user (perhaps just yourself) knows that null is a
valid return value (indicating failure), and you should TEST the return
value in the calling code to see if it is null before using it.

-mbray
 
This doesn't seem to be a correct diagnosis of the error, since (in my
experience) a "throw" suffices as a "return" for a given code path. For
instance, this should compile (and run, and throw) with no problem:

public string ThrowsBeforeReturn() {
int x = 1;
if (x == 1) throw new Exception("Oops!");
else return "no throw";
}

-Marc
 
Daniel said:
Suppose I have a method that returns some type of object, and in that method
I have a try...catch block and just throw my own exception when I catch one.
The compiler insists that all code paths return a value, so...

do I just put
return null;
after I throw my exception in the catch block?

or should I initialize the local variable to null and return it in a finally
block?

or something else entirely, or is it just personal taste?

Thanks.
Click to expand...

A code path that throws an exception does not need to return anything
(in fact, it can't). You should post a sample of what you're doing and
the error you get.
 
This doesn't seem to be a correct diagnosis of the error, since (in my
experience) a "throw" suffices as a "return" for a given code path.
For instance, this should compile (and run, and throw) with no
problem:

public string ThrowsBeforeReturn() {
int x = 1;
if (x == 1) throw new Exception("Oops!");
else return "no throw";
}

-Marc
Click to expand...

You are right - I didn't quite understand the original question (or I
didn't read it correctly)... It seems, however, after reading the
original question, that there WAS a code path that wasn't returning a
value, which would indicate a possible logic error, or just
inexperienced programming. I'm guessing that they wrote code something
like:

public string NoReturnValue()
{
int x = 1;
if (x > 0) return x;
throw new Exception("Oops");
}

and never "returning a value" at the end of the function.

As far as code REQUIRING a return value, you are correct - there's
nothing wrong with the code you've presented. However, I prefer to
reserve throwing exceptions for unusual circumstances where the error is
significant enough that the code can't continue. This is different from
returning an error, which is a "possible expected outcome".

-mbray
 
the errors don't actually have anything to do with each other. If you
rethrow your exception in the catch it makes no difference to anything
you are returning since when the exception comes out its not going to
return a value anyway.

you shouldn't have any 'return' or anything after your throw statement
in your catch block. However, unless the throw is unavoidable in code
then you need to return something at the end of your routine.


Allen Anderson
http://www.glacialcomponents.com
mailto: allen@put my website url here.com
 
Ah, yes you're right.

(I'm trying to work through some sample code and understand what it's doing
as I learn C# and Ado.NET)

It calls a private method in the catch block to actually throw the exception
so that a trace write can be performed in that method as well - good idea
for code reuse but not so good for this compiler constraint. I suppose the
better way to do that would be to put the Trace calls in the custom
exception's constructor overrides, eh?
 
Daniel said:
Ah, yes you're right.

(I'm trying to work through some sample code and understand what it's doing
as I learn C# and Ado.NET)

It calls a private method in the catch block to actually throw the exception
so that a trace write can be performed in that method as well - good idea
for code reuse but not so good for this compiler constraint. I suppose the
better way to do that would be to put the Trace calls in the custom
exception's constructor overrides, eh?
Click to expand...

That would be one way - possibly the best. However, if you do need to
call another method in your catch block you can cleanly work around this
problem by having that method return the exception to be thrown instead
of having it throw the exception itself:

try {
// ...
}
catch {
throw( MyPrivateExceptionLogger());
}
 
Instead of:

void ThrowMyException() { throw new Exception("my message"); }

int MyMethod() {
if (ok) return 1;
else {
ThrowMyException();
return 0; // compiler needs a return or throw here because it does
not know this will never be reached
}
}

I would suggest:

Exception MyException() { return new Exception("my message"); }

int MyMethod() {
if (ok) return 1;
else throw MyException(); // compiler is happy now
}

I don't know if this is really your problem, but it sounds like it.

Bruno.
 
Back
Top