Tuesday, April 17, 2012

 

Error handling

Reminded today of the difficulty of getting one's error handling 100% water tight.

So working away on the HSBC online service, a service which sometimes comes across as being careful to the point of pedantry, when I got stuck. Filled in all the boxes and clicked next to get a message about transaction codes."What...", I think to myself. "I have filled in the transaction code box - a text field - so what is the matter with the thing?" Click on next again to get taken back to the original screen, with some of the stuff that I had entered thoughtfully removed in the interests of online security. Put the stuff back in again and try again. Same result. Maybe another couple more tries. BH suggests letting the thing cool down and trying again later. Eventually it occurs to me that maybe the underscore in the transaction code field is not allowed. Remove the underscore, put the missing stuff back in again and try again. This time it works.

But it could all have taken a lot longer. And not the sort of thing that one would want to ask the helpful BT help service about as that would be deeply insecure. But how long would it have taken the less well equipped HSBC online help service to track down the offending underscore?

Readers wondering about how things might be improved need to grapple with two issues. Firstly, how better to code all the zillions of errors a user might make in such a way that said user sees what the problem is and can fix it. Secondly, how to arrange things so that said code can be passed from somewhere deep in the back end system to the front end system which is actually doing the talking to the user. Neither thing as easy as it might look, particularly if there was a lack of sensitivity to this issue at the time of system design. Which might well have been years and years ago, well  before this particular front end service had been thought of.

Comments: Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?