Confusion about throw and assert

Question

This is the first time I'm writing a library (for me to use on several games) so I think for good programming practice I should comment my code throughly, adding XML summary and use exception handling when user of this library done something wrong like in many .NET classes (the user will likely be me or my teammates)

This is the constructor for NoteRow class (I'm developing music games, by the way) which needs to determine the array's size on creation

bool[] l1NoteData;
public NoteRow(int numberOfNotes)
{
     this.l1NoteData = new bool[numberOfNotes];
}

Now I have this method to toggle the booleans on l1NoteData array.

public void toggleNote(uint index)
{
     l1NoteData[index] = !l1NoteData[index]
}

So here as defensive programming I'd like to check that the index (that user of this class will specify, which is me or maybe my teammates) is out of range specified when creating this class or not.

I've read MANY throw exception vs. assert vs. return bool etc. and still confused and can't choose. Here is my concern :

• Should I putting 'if' statement to check if index is exceeding l1NoteData.length then fire an exception when it is, knowing that exception will fire anyway when that line executed with 'out of range' index? (IndexOutOfRangeException) If so then what is the use of throwing exception? If something goes wrong there will be a default exception anyway?
• I've read that Assert is for programmer. To notice the programmer that the code is not working as the programmer assume. And one can never inject a test case to make the assert fire (if it is fired then the code is wrong) compared to throwing exception which is there to handle abnormal test case (by user). Now the user of this library will be me. So I'm considered a programmer or user? I, as a user of this class may call toggleNote and input index exceeding the limit of array so the exception will be thrown. Or I,as a programmer of my games (this library is the part of my game) should put assert there so I'm not make a mistake of calling toggleNote with over-the-limit index from my game. (that use this library) I can now know the game's code is wrong because assert is fired then fix it and finally made into release build. (and then the assert code will be gone)
• From question above, if I test thoroughly that I'm sure there is no more bug that cause assert to run then go in to release build. I know that assert will not in the code in release build... but is that really good? There are probably more bugs remain in the program so now when user experience that bug, the assert isn't there to catch the bug anymore. So is assert really good thing to use when I can use exception instead and if user cause that exception to fire, I as a developer can receive that bug report to fix it etc. (but the user is me and my friends)
• Throwing exception is 100% better than returning bool to indicate success/failure? What example can you think that is more appropriate to returning bool?

Sorry for my confusing English because I'm already confused with this problem...

Answer 1

Assert is just for testing. Asserts are not used for error handling in a production application

You should pre-check (if) if the input is coming from the user, errors are expected etc.

If an error is completely unexpected, then that is what exception handling is for.

If your own program is providing the index parameter, then it is a bug if the wrong value is passed. Exceptions are fine for this.

Several good questions have been asked on this

Are exceptions really for exceptional errors?

Debug.Assert vs Exceptions

Exceptions vs "if" in C#

Answer 2

The biggest reason for throwing your own exception with a pre-check (simple if statement at the top of the function) is that you can specify your own very detailed exception message. Instead of the default "Index out of array bounds," or whatever it is, you can explicitly say "Hey, dumbass. You tried to toggle a note that didn't exist." Or whatever you want.

The other case for your own exception is for those browsing your library code. You explicitly check for the error and anyone browsing the source of your library will be alerted that this is a potential error. Be explicit in what you're wanting to do in your code.

Answer 3

First. It's usually said, that one benefit of exceptions before return-codes is that exceptions can't be ignored. This gives you the usecase. Use exceptions if you don't want user (programmer) that uses your library to miss something important. Second. I think, you souldn't use assert in general case in library neither as programmer nor as user. I mean that you should use assert in code that uses your library to check you assumptions to be true.

Answer 4

Ask yourself the easy question: do you want to stop it from happening?

If yes, check the index on method entry and throw an exception if it's invalid. This is the usual way in which arguments are validated on a method call.

If no, then you have some options.

• You can use System.Diagnostics.Debug or System.Diagnostics.Trace to record the invalid index, and return silently without doing anything.
• You can ignore it and it will throw an IndexOutOfBoundsException anyway.
• You can guard against it to stop the exception, but otherwise return normally from the method.