(I have no proper introduction to this post, so please insert a perfectly clever and enticing post opening here.)
I'm loving C#! (For non-programmers, C# is a programming language. If that doesn't float your boat, this post will be a bit more nonsensical than usual.) It's proving to be an easy language to learn so far, for the most part. What basics I know about general programming logic (variables, loops, input/output, methods, etc.) is proving to be a great help with getting me through the book I'm using to learn. I'm working my way through Rob Miles' C# Yellow Book 2011, and I think the only thing so far I really don't get is try/catch stuff.*
I'm using Visual Express c~ 2010 for my programming, and also mostly enjoying using it. The Intellisense actually really, really irritates me. For whatever reason, it keeps thinking if I type "i", I really mean "if". But you know what? Using "if" in a "for" loop really causes problems. So I turned it off. SO much easier now.
But, I've noticed it's a bit difficult to sit down to a blank screen and just write a program, even if I know exactly what I want it to do. A few days ago, I sat down and decided to write a mad lib. I was able to hash something together on the screen, but the coding was downright messy. It wasn't organised well, and I didn't make use of the many other things I had at my disposal to do it right. Largely, I imagine, because I expected to be able to just rough it up quickly, like I do a rough draft of a novel.
However, like when I write fiction, I found it much easier to write in on paper. I was able to first write down all the stuff (variables) I needed, then what I needed that stuff to do (methods). Looking at it written down on a piece of paper like a recipe was so much easier. I was able to sit and recode my mad lib from scratch, and as a result it is much more readable and adaptable. I'm quite happy with it, for now. I'm sure I'll find something to add to it later.
Also, I bought a notebook specifically for coding notes and references. Looks like it will become my "program rough draft" notebook, as well.**
*Seriously, it looks like try/catch is only there to catch things you think might cause an error. Surely it's more logical to simply make sure that you're thorough in your coding to make sure such an error doesn't occur? I just plain don't get this, and can't see where I would need to use it.
**As well as lacking a good intro, I'm also lacking a good closing to this post. So, insert a good closing paragraph somewhere. I'm too tired, and I'm going to bed.
Hey,
ReplyDeleteI never used try/catch when I started out either and for rough/test code you generally don't need to.
As you move towards robust production code you need to ensure that *nothing* you do causes fatal exceptions that will cause the program to crash so you start to wrap anything that has the potential to throw an exception in a try/catch loop. That way, not only do you stop the program blowing but you can display a useful error too.
try
{
// Do something a bit dodgy
}
catch
{
// Make sure you sort it out if it blows up, rather than terminate the program.
}
Fair enough. There's a few other bits and pieces that I understand how they work, but not when I would need to use them. I imagine those, too, will become clear as I move forward with my coding! :D
Delete