standard error development

[ddellostritto]

Hi all -

I'm starting out as a designer and have some knowledge in php development. I've designed a registration system for my company and we've had 3 people that have had problems out of 73 successes - 4.1% (Problems meaning that they registered but the data just didn't get into the database. The registration system allows them to select an event, specify their user type - individual or group - and register their information.)

I was wondering: What is the average number of errors that I can expect to have when developing?

I have a feeling that there will always be some errors, but I would like to have some number or statistic to aim towards and so that I can calm my manager (not a tech person).

Any help much appreciated.

My layman's take on errors is that you test, test and test again before anything goes live. Of course, there will always be bugs or unexpected results, but these should be at a minimum for a straightforward registration form.

Ensure that all input is validated and that security is ramped up to the max possible, while still making the form accessible.

The errors encountered need to be tracked. Are they user input errors - e.g. validation errors (example - wrong number of chars in a password field, or incomplete data being submitted). Are they connection or SQL errors (DB). As it seems critical to your company, you need hard data about the nature of the failures to troubleshoot effectively.

I don't know if a %age error will be of much help here. If the proportion of errors are validation-based - could your form design be at fault? Is it too complicated, unintuitive to use? Does it rely on javascript?

Is your manager getting hot under the collar? Losing data may cost money, which may cost jobs. Whether he's a tech person or not, he's probably got a bottom line and will get his bottom toasted by his boss.

Perhaps if you share your code, we could have a look?

[ddellostritto]

@ardav thanks for the feedback!!

I did lots of tests before I launched, from several different machines (pc and mac) and tested until I was satisfied with the results.

Ideally errors would be 0, and I understand my manager totally - I studied business admin so I know all about it; but I would like to have some sort of benchmark to help guide any response I give her.

The system I designed has a few too many files to share here and doesn't use any javascript (I tried to make it as simple as possible for the users).

I will say that I don't have any error tracking going on, and really not sure how I could do so. This means that I don't have clear info about where the problems are stemming from. Any suggestions?

Thanks again!!!

Yep, sorry about the business quote :(

On a live site, logging and error tracking are vital. Ensure that all processes can capture errors. So form submission should include server-side validation that will feed into an error trapping routine and log problems - if these are few in number, then user input can be blamed and you may need to look at the form design - are there ways to make it more intuitive or to set default values or enumerated types. Do fields need a small amount of explanatory text to guide users. Sometimes client-side validation can help to reduce the cases of sending invalid data - they may stop submission and highlight errors or incomplete fields.

If the logs show DB connection or SQL errors (you can use the 'die' approach, but a more sophisticated system may be appropriate), check that all input is sanitized properly in order to avoid breaking statements.

If your 'logged-in' status depends on cookies or sessions, again ensure that these are robust.

Error trapping and reporting can be a pain to set up, and in the development phase, it may be a simple 'else' print 'PROBLEM' to screen. I have had good results with the 'try and catch' system. Maybe something to consider.

If you are adept at OOP, perhaps having an error-trapping class may be a way forward. I must admit, I tend to struggle with this.

There are far more experienced members than me on this site who should be able to help you further - but setting up a logging system and error trapping routines would be my approach.

[pritaeas]

Agree with ardav here, you'll have to log anything that can fail. Personally, I like log4php since you can set logging levels, without having to touch the code. Logging to file is in my opinion better then to database, since the database connection could fail too.

Basically any code that can fail, either with a return result of false (invalid queries), or something that raises an exception (invalid objects) should be logged.

Since you don't have any logging, perhaps you can use your database log, to see if the problems where in queries (unless you didn't turn that on of course).

About the average failure... you are dealing with user input. You have to be completely paranoid, and not trust a user with any decent input. If you fail to check one possible input, you can expect several possible points of failure.