|
|
Posted by Dikkie Dik on 09/02/06 09:15
Would you call a PHP programmer that does not check for errors a
professional then?
Most web sites developed with PHP are a kind of "robot" that represent a
company or person. Think of any web shop, for example. People pay real
money when buying things through the internet.
Nobody is perfect, off course. So people do make mistakes. But when my
"robot" makes a mistake (better said: discovers a mistake that I have
made), I would like to know about it. So it saves any errors into a
table or file, or sends it to me by e-mail.
> ... I recently worked on a project where someone
> suggested to me I was spending too much time writing error messages,
> and that I was therefore missing the benefit of using a scripting
> language. The idea, apparently, is that the PHP interpreter writes all
> the error messages that are needed, and that I shouldn't write such
> code myself.
I am totally flabbergasted by this. First, these error messages are for
you, the programmer. They can contain sensitive data about table names,
file names, etc. You don't want to show the internal PHP message to a user.
Furthermore, because these messages are meant for you, you will miss
them if they are only shown to a user. Especially if they are hard to
reproduce.
> I was given the impression that if I needed extensive
> error checking, or strict typing, then I should use a real language,
> like Java, but if I'm going to use a scripting language like PHP or
> Ruby, then I should leave errors to the interpreter, since the whole
> point of using scripting languages is speed of development.
What a load of crap. On what planet his this person been for the last
decade? PHP is an object-oriented language that is still backwards
compatible with hacker-style or "blind panic" type of programming, but
has outgrown it since long.
To speed up development, I have written classes that I share between
projects (using SourceSafe or Subversion). So, database handling is
something I have written just once. Error logging is something I have
written just once. And so on. If you want to speed up development,
prepare your code for reuse.
> Has anyone
> else heard this argument, and do you agree with it? I'm wondering how
> other PHP programmers handle error messages. Check everything or leave
> it to the PHP interpreter to tell you when there is an error?
I already answered that one, I think. Besides that, I write unit tests
to get a feeling of the quality of my code. If error handling is already
thought bad, writing unit tests will probably cost you your job.
But I still recommend them. They force you to program in a much more
modular way, and they take away a lot of complexity when a project gets
larger.
> function getWeblogEntries() {
> $query = "SELECT * FROM weblogs";
> $result = mysql_query($query);
I would check mysql_errno($connection) to see if MySQL really was told
something it could understand. If not, make sure a developer gets the
message returned by mysql_error($connection).
> My own feeling, obviously, is that it is better to error check
> everything, and to write extensive comments everywhere. I've taken over
> PHP projects, started by other programmers, that had no error checking
> and no comments, and such projects are always a big pain in the neck. I
> lose time playing Sherlock Holmes, trying to track down where a
> function's parameter first originates and why it's in use. I'd rather
> have a comment on it, and error message for when the wrong thing is
> passed in.
There's even a better way: use good names instead of comments. Lots of
editors feature some autocomplete or intellisense that show you the
variable name. Consider:
function item($i) // $i is a one based integer
versus
function item($intOneBasedIndex)
In the last case, your editor will show this "comment" when you use it,
not just when you define it.
> Obviously this slows development.
Huh? You did all the Sherlock Holmesing in your own free time then? I
also worked for a company that thought all quality as bad and too
expensive. Most of my tasks involved writing or correcting two lines of
code, and took at least three days trying to find which lines or where I
could insert them. Now THAT is slowing down development.
> Is there any concensus
> among developers about what is the best approach? I think whatever is
> cheapest for the client should be considered the best approach, but it
> seems to me cheapest-in-the-short-term is quite different from
> cheapest-in-the-long-term.
I think you get the point.
Best regards
Navigation:
[Reply to this message]
|