Today we encountered a problem where we were trying to pull a line out of a resource bundle to display to the user, but because of a type-o in the key we were using the lookup failed resulting in a lovely null pointer stacktrace on the screen. Naturally this was on the ready-for-release build. I guess this is why they leave a week between the last build and the scheduled production push. 😉

Due to the inconvenience and embarrassment of missing it I put in my root cause analysis and defect prevention hat. Once the hat was nicely settled, I remembered I wrote a script at HP which found this sort of problem. I don’t think I have the script anymore, and even if I did it was too customized to HP’s i18n solution to be practical to share. Essential what it did was parse the resource bundle to get the list of available strings and compare that to a list of requested strings as derived by parsing the source code.

The results of this script tell us a couple things about the relationship between the resource bundle and the code

  1. In resource bundle but not in code
    • No longer used resource string that should be removed
    • Resource string should be being used, but is not
  2. When a resource key is in code but not in resource bundle, as today would illustrate you are going to get a null pointer. (At least I will, your app might behave differently). Or what is more likely is that you have a type-o in one side of the equation.

I originally wrote the script in Python and would do so again if I got the time/blessing to, but I think it would be more useful (my my case) if it was written as a junit test which could then be run every time the component was built. Or better still, applying the concept of fail fast it would be a pre-build task so the time creating a binary would not be spent.