Bugs: Gear score exception and deleting an entry

Luckily Path of a Hero has not contained to many bugs and the vast majority of people have been able to use and enjoy it without problems. That said there have been two bugs that stood out and I am glad to say that I think I have fixed them.

Gear Score Exception
Some users were experiencing an exception (which would pop up in a dialog box) when they attempted to make an entry.

Something like this

Exception: Traceback (most recent call last):
File "/home/pathofahero/common.py", line 85, in wrapper
return func(*args)
File "/home/pathofahero/Entry/views.py", line 67, in makeEntryAsync
score = getScore(hero.zone, realm, character)
File "/home/pathofahero/Entry/beImba.py", line 31, in getScore
result = result['result'][zone][realm][character]
KeyError: u'Sentinels'

To fix this I first made the code more defensive so that if something like this happened the gear score would just default to 0, so that an entry could at least be made. Secondly I made the server email me with more specific details about what went on.

Within 10 minutes I had received an email and it was quite clear what the problem was. I was expecting realm names to stay in the same casing as I passed to Be Imba however it was returning realm names in lowercase (only sometimes) . For example I would pass in 'Sentinels' to the web service and it would return 'sentinels'. This obviously threw my system because it was not expecting this to happen.

After identifying the problem it was obviously trivial to fix and now hopefully users will not have any more problems.

Deleting an Entry not working
Quite regularly I was receiving emails telling me that something was going wrong when people deleted an entry. This was quite difficult for me to diagnose because I could not reproduce the problem. Any programmer will tell you that 'unreproducible bugs' are the worst thing to have to deal with.

In the end through a process of elimination I believe that the error was caused by the flex app (journal) caching when it is not supposed to and thinking it still has access to entries that are in fact deleted.

My solution to this was to once again make the code more defensive. I gave the journal the ability to be dynamic. If it tried to access an entry that no longer existed, it would be told this by the server and it would then request a *true* list of all current entries so that it can internally update.

Whilst my solution is sound on paper, since the problem is unreproducible, only time will tell whether this correctly solves the problem. :)

Now it is time to move on to suggestions :D