[gdp]

Try to consider all possibilities for failure and all inputs or contingencies. If you are still coding and don't want to interrupt your "flow" to go write an error handler, just put an assertion or a comment or something that will force you to go back and write it before you compile. That way you'll know when the problem is actually solved.

With that in mind, perhaps also think about the way you are structuring your development. Do you have a mental (or physical) sketch of the code before you write it? There's something to be said for having a bit of paper to scribble on before and during the coding process. Map out little examples (e.g. "test cases") and think about how you will deal with all of them.

Finally, writing stubs (i.e. functions or modules that are basically empty) when you first start can be great. If you know you're going to need some pieces of functionality in order to solve your problem, then write stubs for those and then solve the problem (i.e. write the main program flow). Hopefully then when you come to write the supporting functions that do most of the heavy lifting, you will have clarified your intuitions around how they are supposed to work.

So my advice would be to be a little more rigorous in your approach _before_ you get to the point of having screenfuls of code in front of you.