Why PHP sucks #1

Welcome to my series of posts of why PHP is the worst language I've ever had to work with. Today's topic is error handling. Or perhaps PHP's lack of it. One of PHP's philosophies seems to be that the programmer should not be troubled by any nasty errors. It's better to attempt to do something even if that is wrong. Failing fast with a clean error message and a stack trace is not one of PHP's virtues.

PHP seems to (I'm just guessing here) have only had errors (with different codes for warnings, notices etc.) before. Now it also has exceptions. This is pretty annoying because you end up having to write your error logging code. This involves setting up your own custom error handler which rethrows the errors as exceptions. Then you can add your own custom exception handler which can obtain a stacktrace from the exception and print it out inside <pre> tags so that you can make some sense of it.

Then you figure out that PHP treats "fatal errors" differently. It bypasses your error_handler and just shuts down your application instead. Then you figure out that you can register a shutdown function and try to output a stacktrace manually from there. Unfortunately by the time this function is called PHP has already torn down most of the stuff you were using and the only thing in your stacktrace is gonna be your own shutdown function.

So you end up installing the xdebug extension and by enabling it you can finally get some output when your program. Except it's a big mess of lines where you end up just having to go through all the mentioned lines to see if you can figure out what's causing your problems. Then after a while you notice that you can echo a single opening <pre> tag at the beginning of your script while debugging your errors and suddenly all the output from xdebug is quite readable. But the fact that you have to go through all of this crap shows why PHP sucks.

Programming books I read in 2010

I read quite a few programming-related books in 2010. Here are the ones I can remember:

Tehokas Java EE-sovellustuotanto

Perhaps the most important book I read all year. Helped me in getting my current job. Taught me the basics of Maven, Hibernate, Wicket, Spring and so on. All of which were needed in the first project I was working in.

Javascript: the Good Parts

Very nice book. I read this for the Javascript study group we've started at my workplace. Recommended to read more than once if you really want to learn Javascript.

Effective Java

Very good Java book.

Refactoring to Patterns

I just skimmed through the descriptions of the patterns and skipped most of the longwinded refactoring instructions. If I remember correctly the smaller refactorings of Martin Fowler's were more immediately useful.

Patterns of Enterprise Application Architecture

While the content of this book was different from what I expected based on the "enterprise application" of the title, it was still a very good book. It taught me more about how Hibernate works. And I've referred to this book a few times when refactoring a project at work.

The Pragmatic Programmer

I had already read this one before. I just read through it again because it was such a long time since I last read it and because it's such a short and easy read.

Facts and Fallacies of Software Engineering

Sort of interesting. The abstraction level was quite high. I was aware of many of the ideas in the book already.

Pro Git

Online book about git. In 2010 I greatly improved my understanding of Git. This book was one of the best sources for learning about it.

CSS Mastery: Advanced Web Standards Solutions

HTML and CSS is one of the biggest pain points of making web applications. One of the things I remember the best from this book was how often the chapters had to have some extra workaround crap instructions for IE and what a pain in the ass it is to make rounded corners.

Rails Recipes

This one was written for Rails 1, so it was a bit out of date. At the moment, I can't really think of any useful recipes I learned from this.