System.StackOverflowException

[Amy]

I'm getting a System.StackOverflowException, and I can't see why.
Here's the code that's throwing the exception. I don't see anyting
that's recursive about it. Any help is appreciated (including help in
debugging - I'm not sure what I'd put in a try or catch clause here):

DataDealings sql = new DataDealings();

myProject = sql.GetProject(pID);

-------------------------------------------------------------------------------------

public Project GetProject (int pID)
{
Project p = new Project();
p = null;

SqlCommand cmdGetProject = new SqlCommand("PC_Return_Project", conn);
cmdGetProject.CommandType = CommandType.StoredProcedure;
cmdGetProject.Parameters.Add("@pID", pID);

conn.Open();
drProject = cmdGetProject.ExecuteReader();

if (drProject.Read())
{
p = new Project();
p.ProjName = drProject["projName"].ToString();
p.ProjDescrip = drProject["description"].ToString();
p.ProjRequestedDeadline = drProject["requestedDeadline"].ToString();
p.ProjBasecampURL = drProject["basecampURL"].ToString();
p.ProjStatus = drProject["Status"].ToString();
p.ProjStatusID = Int32.Parse(drProject["statusID"].ToString());
p.ProjFreq = drProject["freqtype"].ToString();
p.ProjFreqID = Int32.Parse(drProject["freqID"].ToString());
p.ProjPriority = drProject["priority"].ToString();
p.ProjPriorityID = Int32.Parse(drProject["priorityID"].ToString());
p.ProjDateProposed = drProject["dateProposed"].ToString();

drProject.Close();
conn.Close();
}

return p;
}

 

[The Crow]

stack overflow almost always happens when infinite recursive method calls
occur. probably, in a property of Project class there is such code :

private string projName;

public string ProjName
{
get
{
return ProjName;
}
set
{
ProjName = value;
}
}

 

[Vadym Stetsyak]

when do you receive the exception (on what line of code)?

 

[Amy]

Yeah, there is!
Can you explan to me why that's recursive?

TIA,

Amy

 

[Amy]

I don't know - the error doesn't give me a line number.

 

[The Crow]

recursive is, when a method calls itself. here is a better code snippet to
explain. function calculates i! :

private void Functionel(int i)
{
while(i > 0)
i = i * Functionel(i - 1);
}

 

[The Crow]

you have to learn "Debugging" (if you dont know).

 

[Guest]

In it’s simplest form, recursion is just calling the same function or method
over and over again from within that function or method.

In Crow’s example, ProjName and projName are different identifiers within a
block of code, and requesting the value from ProjName attempts to return the
value from ProjName (capital p) rather than from projName (lowercase p). In
doing so, the get portion ProjName of is continually called without end until
you run out of space on the stack.

Brendan

 

[Bill Butler]

Yeah, there is!
Can you explan to me why that's recursive?

OK,

remember that properties are really nothing more than methods that use different syntax.

Case 1 (Recursive); never reference x
private string x;
public string X {get {return (X);} set {X = value;} // this is recursive

----------------------
Case 2 (Nonrecursive); we do reference x
private string x;
public string X {get {return (x);} set {x = value;} // this is NOT recursive

----------------------
It is easier to see the recursion in case 1 if we change the property name.
Case 1 Mark II (Recursive) never reference x
private string x;
public string Qwerty {get {return (Qwerty);} set {Qwerty = value;} // this is recursive

Nowhere do you reference the member x.
Any call to Qwerty will keep calling Qwerty forever.

Hope this helps
Bill

 

[Jon Skeet [C# MVP]]

I'm getting a System.StackOverflowException, and I can't see why.
Here's the code that's throwing the exception. I don't see anyting
that's recursive about it. Any help is appreciated (including help in
debugging - I'm not sure what I'd put in a try or catch clause here):

Could you post a short but complete program which demonstrates the
problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.

One thing which is odd though:

Project p = new Project();
p = null;

Why bother to create a new object, assign a reference to a variable,
and then set the variable's value to null straight afterwards?

Do you have a stack trace from the exception? That would help a lot.

As for debugging: I suggest you try breaking into the debugger at the
start of GetProject, and then just step through the code...

 

[Jon Skeet [C# MVP]]

Yeah, there is!
Can you explan to me why that's recursive?

Well, what do you expect

return ProjName;

to do?

Note that the name of the variable is projName - ProjName is the name
of the *property*.

 

[Amy]

Unfortunately, I can't run the debugger on my projects (it has to do
with permissions in my development enviroment, which I don't have
control over), and I didn't get a stack trace on this error, either.

My thought regarding setting p to null was in the event that the
stored procedure didn't return a project, the value ought to be null.
Am I missing something conceptually?

I understand the nature of recursion, what I was missing was the case
sensitivity - that is, I know c# is case sensitive, but I'm still not
good at noticing when I've mixed up my cases.

Thanks, everyone, for the help!

--Amy

 

[Jon Skeet [C# MVP]]

Unfortunately, I can't run the debugger on my projects (it has to do
with permissions in my development enviroment, which I don't have
control over), and I didn't get a stack trace on this error, either.

If you can't run a debugger, you're being stifled in development.
Personally I don't use a debugger much, but it's definitely worth
kicking up a stink about that.

My thought regarding setting p to null was in the event that the
stored procedure didn't return a project, the value ought to be null.
Am I missing something conceptually?

It's not the fact that you're setting it to null that's the problem -
it's that you're creating a new project for no reason. Why don't you
just do:

Project p = null;

instead?

I understand the nature of recursion, what I was missing was the case
sensitivity - that is, I know c# is case sensitive, but I'm still not
good at noticing when I've mixed up my cases.

In that case, I'd suggest using a different naming convention for your
variables, eg m_name instead of name. Personally I prefer name (and
Name for the property) but if it's likely to cause errors like this,
it's worth changing.