catch (ArrayIndexOutOfBoundsException customColors)
That's the worst way to handle such problem...
A try / catch is slow, and should be used only to catch truly exceptional problems (like I/O exceptions).
It is much simpler and faster to check the index against the bounds of the index:

1. if (idx < customColors.length) {
2.   // use customColors[idx]
3. } else {
4.   // use default color
5. }

Also, you might be interested by the Why use ArrayList instead of array with append()? article...

Thanks for the help....but in case I'll need to use a try/catch interface in the future....is there a solution to my problem?

" is there a solution to my problem?" " The fill color remains white"
Of course it remains white, that's the color you append to the array! Change 255, 255, 255 to 255, 0, 0 in the uncommented line and you will see red...

" Why is try/catch so slow?"
Honestly, I don't know, that's what people keep saying...
I think that's because the try / catch need to setup a special mechanism, check if there is a try in progress when an exception is thrown, and go to the catch location if found, or something like that.
Frankly, perhaps this slowness is really no measurable in a regular sketch...
So let's say that this mechanism should be avoided for runtime errors like NullPointer or ArrayIndexOutOfBounds exceptions because:
- These errors are easy to avoid from regular constructions:
  In your case, you can just put a default value directly in the constructor, so you never have the AIOOBE as long as the index is correctly managed; or as I shown, at worst you can test the bounds like I shown.
- The try / catch is a special construction made to catch unexpected, or unpredictable (I/O or network errors for example) problems, but NPE and AIOOBE are very easy to expect / predict / avoid... Using this construction in such circumstances is rather confusing. And can hide another error, less expected, leaving without a clear message from the JVM.
- And well, it is quite verbose and annoying to type! (and to read)

It is a powerful mechanism, not obvious to master (that's why Processing catches all exceptions for the user, hiding them), but not to use everywhere.
A bit like the ArrayLists: they are very handy, but one must know when they are needed: you should not use them everywhere you used regular arrays, when the size is fixed and known, because their usage has a (little) cost.

Thanks for the help. I have hit another (hopefully final) roadblock. How would I delete a position in an array, and move the following positions down one spot. For example, I want to delete the position someArray[2] -

This kind of question has been asked many times before, especially in the old forums...
Take a look at this post.

I usually do something like this (it's pretty messy, though):

1. int[] inputArray;
2. int removePos;
3. 
   
4. int[] outputArray = concat(subset(inputArray, 0, removePos), subset(inputArray, removePos + 1, inputArray.length));
   

The code below will delete the element at position pos and then shorten the array. If you want to delete values from 'inside' an array then it is more efficient to use an ArrayList but in this instance you will not notice the difference in performnce.

1. if(pos <= 0 && pos < someArray.length){
2.       // Move elements down one position
   
3.       for(int i = pos; i < someArray.length -1; i++)
4.             someArray[i] = someArray[i+1];
5.       // Shorten array by one element
   
6.       shorten(someArray);
7. }