Your highest priority should be to learn to use the debugger. It might sound advanced... but it isn't. You will be able to spot the course of errors like this in seconds - even without a heap of experience. Sure some errors will still be tricky... but if they are tricky with a debugger, they are pretty much impossible to solve without.
All you have to do is set a break point in the code you see a problem with (F9 in Visual Studio default key binding). Start the program with the debugger attached (F5) and reproduce the problem. Now you can step through the program line by line (F10/F11)- and you can see the values of all variables and fields at each line in the program.
Spotting the setter calling itself is trivial this way. As a beginner you might still want to ask help on how to solve a problem once you identified it - but at least you can ask a much more precise question when you know what the error is - and get help a lot easier.
So please - take the time to learn the debugger. The half hour will come back with interest of a few million percent.
Rule number 2 when troubleshooting (rule number one is "use the debugger") is not to assume anything. Assuming your debugger won't show you what is wrong is not the right approach.
What would happen if you had spend 10 seconds setting a breakpoint in the getter and setter and then kept pressing F11: You would see your code repeatedly call itself, while the callstack keeps growing one line each time it calls itself.
Error messages which tell you about spelling mistakes or other syntax errors are generated at compile time of your program. No executable is produced and therefore your program doesn't run.
A stack overflow condition can only occur when your program has been compiled and started running.
The debugger is the tool to be used for analyzing run time errors.
You should learn to understand the difference between these to error types.
Hitting F5 doesn't "turn on the debugger". It launches the result of compiling whatever is tagged as the "Startup project", and its dependencies, then the debugger is "attached" to the launched process.
There are two sets of error messages, compile-time and run-time. All of the messages that tell you "what's wrong and how to fix it" are at compile-time, before you even have an .EXE to run. These are syntax problems with your code.
The other messages show up at run-time and tell you how your code failed to execute somewhere. These are related to very specific problems with some action your code is executing, such as "Access Denied" or "File Not Found". These message never show up at compile-time and will only give you a hint of what to look for when stepping through your code and inspecting variables. These are problems with the logic in your code. Quite often you can write syntactically correct code and it will compile, but when it comes to running it, you can have all kinds of problems.
Seriously: Are there really people out there NOT using a debugger when developing code?
To me that is like climbing Mt.Everest blindfolded, all on your own.
There may be extreme exceptions where no traditional debugger is available or can't be used, e.g. in a certain class of embedded systems where the code is in flash memory and cannot be modified on a byte or word basis, so you can't poke debug interrupts. Or the processor is so primitive that it doesn't provide interrupts, or doesn't give sufficient external access to the address bus to run a probe on the outside. But those are very special cases. And I have never seen a system where you cannot do "printf style" debugging by setting output signals - even 8-bit embedded processors offer that (otherwise, how would they control what they are supposed to control?)
Those special cases are lightyears away from desktop development in C#. If you run a company, you most certainly can affort the investment in, say, Visual Studio. For hobby programming, there is a free version providing so near-100% functionality that you probably won't notice the difference. (There are some differences, but they are rarely relevant for hobby programming.)
Even printf debugging can work well in some cases (sometimes it is usesful as a companion to the interactive debugger, e.g. to traverse data structures and print selected values if this requires more processing than a simple watch expression).
But "debugging by cranial massage", as one University lecturer phrased it. is not sufficient.
No. Errors at compile-time are just syntactic problems with your code. The compiler cannot compile the code into an executable when these show up. They have nothing at all to do with the logic of your code.
Debugging comes into play when you actually start running the code.
It enters the Gold getter, which returns the value of ... the Gold getter. Which returns the value of ... the Gold getter. Which returns the value of ... the Gold getter. ... until the stack blows and your app crashes.
The same happens when you try to use the setter: it infinitely recurses trying to set itself!
Create a private backing field:
privateint _Gold = 0;
if (value == 20)
value += 5;
_Gold = value;
And it'll all work.
Sent from my Amstrad PC 1640 Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!