[RESOLVED] Writing Fail-Safe Code

[Guidosoft]

Okay, this is going to be a very embarrassing question for me, but I nonetheless need to adopt the best practices for writing code.

I need to know what is the best way of keeping my code from breaking. I understand that I should probably write methods that are of themselves fail-safe. I should probably validate all the arguments passed to a method and throw an exception when an argument is invalid or will cause the code to break. I should also probably validate conditions after the meat of the method has done its job, and throw an exception if that isn't right. (Although I would like some explanations about this to solidify the concept.)

I have several situations that I can think of where I can keep my code from breaking, but it requires that I employ exception handling strategies that I am not intimate with. Something very simple like refusing to accept a property value which is an array if it contains a null reference I would have a little trouble with, simply because I do not know what the is the right exception to throw in that situation. Some exceptions I know what to do with are, ArgumentNullException, ArgumentException, and quite a number of others that are more specific to .NET APIs. But I do not know the proper exception to throw when the argument is a collection that has an invalid value, or when it is not an argument, but a property value, whether it is being set a the time or being used for some purpose.

I need to know these very fundamental things. I am already familiar with many other things that are far more advanced, but playing around in my personal time I have not made my code solid. It is, however, required of me to implement fail-safe code. (Please don't comment on this matter.) So, I would like some information on how to best go about this, because I no longer wish to go by sloppy coding practices.

Thanks in advance for the help.

[BioPhysEngr]

First, fail-safe code does not exist for any non-trivial application and anything required to not fail (e.g. avionics) in almost any circumstance is expensive to develop.

That said, the most important thing you can do is to keep your code modular. Don't write an extremely long subroutine. Instead write 5 short subroutines, each of which accomplishes a limited goal and then tie them all together with a 6th subroutine that calls the other 5. If every subroutine can be understood and mentally-verified correct, it's a lot easier to debug.

Validating of arguments is good. You can also use System.Diagnostics.Debug.Assert statements to verify conditions.

More information on exceptions is at MSDN: http://msdn.microsoft.com/en-us/libr...=vs.80%29.aspx

Basic wisdom: Try not to write functions that are hard to understand; break them up into brain-sized units.

[CreganTur]

I'm mostly going to echo what was said above.

Keeping your method simple in function will give you better control over the application and make it easier to track and fix errors.

Try/catch is your friend, especially if you have specific errors you want to catch and deal with in specific ways. Debug your code constantly, set watches, and try to break it- this will help you see all the ways it can go wrong so you can spot problems and create solutions.

Validation is very important, but depending on what you're validating a simple method can accomplish a lot. If you have a user interface you can reject anything that is invalid and prompt the user with a reminder of what is valid- that reduces the validation code you have to write and teaches your users how to use the program correctly.

You don't have to throw specific types of exceptions unless you need to deal with that exception in a specific way. Otherwise, you can just do something simple like post a message that an error occured or extend the existing error class to handle them in appropriate ways.