return null upon exception?

[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.

[Michael Bray]

"Daniel Billingsley" <db**********@N O.durcon.SPAAMM .com> wrote in
news:u3******** ******@tk2msftn gp13.phx.gbl:

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?

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

[Marc Lewandowski]

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 ThrowsBeforeRet urn() {
int x = 1;
if (x == 1) throw new Exception("Oops !");
else return "no throw";
}

-Marc
"Daniel Billingsley" <db**********@N O.durcon.SPAAMM .com> wrote in message
news:u3******** ******@tk2msftn gp13.phx.gbl...

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.

[mikeb]

Daniel Billingsley wrote:

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.

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.

--
mikeb

[Michael Bray]

"Marc Lewandowski" <ma**@telebill. com> wrote in
news:OJ******** ******@tk2msftn gp13.phx.gbl:

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 ThrowsBeforeRet urn() {
int x = 1;
if (x == 1) throw new Exception("Oops !");
else return "no throw";
}

-Marc

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

[Allen Anderson]

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
On Wed, 15 Oct 2003 11:24:51 -0400, "Daniel Billingsley"
<db**********@N O.durcon.SPAAMM .com> wrote:

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.

[Daniel Billingsley]

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?

"Marc Lewandowski" <ma**@telebill. com> wrote in message
news:OJ******** ******@tk2msftn gp13.phx.gbl...

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 ThrowsBeforeRet urn() {
int x = 1;
if (x == 1) throw new Exception("Oops !");
else return "no throw";
}

-Marc
"Daniel Billingsley" <db**********@N O.durcon.SPAAMM .com> wrote in message
news:u3******** ******@tk2msftn gp13.phx.gbl...

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.

[mikeb]

Daniel Billingsley wrote:

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?

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( MyPrivateExcept ionLogger());
}
"Marc Lewandowski" <ma**@telebill. com> wrote in message
news:OJ******** ******@tk2msftn gp13.phx.gbl...

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 ThrowsBeforeRet urn() {
int x = 1;
if (x == 1) throw new Exception("Oops !");
else return "no throw";
}

-Marc
"Daniel Billingsley" <db**********@N O.durcon.SPAAMM .com> wrote in message
news:u3****** ********@tk2msf tngp13.phx.gbl. ..

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.

--
mikeb

[Bruno Jouhier [MVP]]

Instead of:

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

int MyMethod() {
if (ok) return 1;
else {
ThrowMyExceptio n();
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.

"Daniel Billingsley" <db**********@N O.durcon.SPAAMM .com> a écrit dans le
message de news:O1******** ********@TK2MSF TNGP12.phx.gbl. ..

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?

"Marc Lewandowski" <ma**@telebill. com> wrote in message
news:OJ******** ******@tk2msftn gp13.phx.gbl...

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 ThrowsBeforeRet urn() {
int x = 1;
if (x == 1) throw new Exception("Oops !");
else return "no throw";
}

-Marc
"Daniel Billingsley" <db**********@N O.durcon.SPAAMM .com> wrote in message news:u3******** ******@tk2msftn gp13.phx.gbl...

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.