At what point do you stop worrying about errors?

[NTB]

messing with a little file-consolidation process for work here, and started wondering about this...at what point should you stop worrying about (and planning for, and programming around) possible errors? Even with this little Perl script that I'm working on, there are a bunch of things that could fail, but the odds are pretty slim for most of those: file copies / renames / deletes / openings (for read or write), files not found, empty files, you name it. So even the simplest program could become majorly and needlessly complex. So when or how do you decide to quit worrying about 'what ifs' and just concentrate on the task itself?

Just curious to see people's oppinions on this. I've been out of college for a while, but only been working in programming for ~2 years...so I'm still trying to find a good answer to this for myself.

Nathan

 

[Woosta]

Who's going to use the program? Yourself or is this going to be redistributable?

 

[NTB]

Originally posted by: Woosta
Who's going to use the program? Yourself or is this going to be redistributable?

In this particular case, it's an automated process; nobody actually 'uses' it, other than possibly re-running it manually, if needed. It'll be running on a single server machine at work. That said, I do need it to send out an alert - an e-mail - under some conditions. I already know how and when to do that, though.

Nathan

 

[drebo]

For intenal-use applications and applications that you support and maintain yourself (obviously depending on the number of users...1000 users and you'll probably not want to treat it this way), clean error handling is not such an imperative concern unless it's on a data process where possible corruption could happen.

That said, your error logging should always be sufficient that you can easily and quickly track down a possible bug. So, if your script errors out on a particular file, you should get an email specifying the file name that it errored on as well as what stage in the process that file was at.

But, clean error catching and handling probably isn't that huge of a deal. You just need to make sure your logging is good enough to be useful in tracking down a bug.

 

[NTB]

Originally posted by: drebo
For intenal-use applications and applications that you support and maintain yourself (obviously depending on the number of users...1000 users and you'll probably not want to treat it this way), clean error handling is not such an imperative concern unless it's on a data process where possible corruption could happen.

That said, your error logging should always be sufficient that you can easily and quickly track down a possible bug. So, if your script errors out on a particular file, you should get an email specifying the file name that it errored on as well as what stage in the process that file was at.

But, clean error catching and handling probably isn't that huge of a deal. You just need to make sure your logging is good enough to be useful in tracking down a bug.

This is pretty much what I'm doing already, then. Like I said, there will be no direct users for this little script, unless someone needs to re-run the process manually for some reason. Under normal conditions, it's just an automated process that runs at a pre-set time to read and format data from a bunch of little files to a single, larger file. The data in this larger file is later used to update the database that underlies one of our applications.

Nathan

 

[sourceninja]

I have a large library of functions I have written for 99% of most error handling cases I run into. I use them in all of my projects. I also write unit tests before I start actually coding the program. It is just a function of habit. If it was flr use by anyone but me, then I make sure to close any hole I can see a user falling into.

 

[chronodekar]

I agree with drebo.

If you are going to be the only one to use the code (or have an Apple-like monopoly of where the code will be used) you can skip error-handling. The idea being, that IF anything goes wrong, you won't have to hear complaints from anyone. The exception to this rule, as stated is when you cannot afford to have your data corrupted.

It might be a good idea, to have a command-line output saying "Error-checking NOT implemented" or the like as soon as you run the code. That way anyone running the code will know to expect anything. Otherwise, you might end up in a situation where 2 years down the line someone will be screaming at you for writing bad code.