Why you shouldn't suppress errors in PHP using the @ operator

A brief story about Code Igniter, a blank white page and MS SQL Server

Today I was setting up a project in Code Igniter that connected to a Microsoft SQL Server database (in my case it was a local instance of SQL Server 2008 Express) and I kept experiencing an incredibly unhelpful blank white screen.

Now I’ve worked with PHP for about 8 years professionally but never spent a huge amount of time with Code Igniter so it was all a little new to me. However, having previously worked with a few other MVC frameworks it didn’t take long for me to find my way around and become familiar with it. After performing a few checks and double checks to make sure I wasn’t doing anything silly I still hadn’t come any closer to figuring out why Code Igniter was throwing me a blank white page.

I started to dig down into the way Code Igniter was connecting to the SQL Server database via its MS SQL Server driver and it suddenly hit me - I’d fallen victim to the “we don’t like seeing errors so let’s suppress them by using the @ operator” school of thought.

That’s right, Code Igniter’s MS SQL Server driver was suppressing a simple error that would have helped me solve the problem within minutes. Interestingly I’m not the only one who appears to have fallen victim to this either.

Why suppressing warnings and errors is bad

One common reason some might advocate suppressing errors is that showing errors to users is not only messy and unprofessional, but also poses a potential security risk as often errors or warnings can contain important configuration information such as database names and sometimes even usernames or password. This is a perfectly valid concern; HOWEVER, errors are thrown for a reason. Something somewhere is going wrong and it’s important that errors are handled correctly. Ignoring errors is not handling them.

One way to correctly handle such errors is to wrap the cause of the potential error in a try catch statement and output any occurring exceptions to a log file. Doing this not only prevents users from seeing the error but also provides us with a way to track if an error is being thrown in the first place, something that can become increasingly important as an application or website grows in size and traffic as the suppression of errors can start to affect performance.

And, as my story above highlighted, you’re no longer hiding an important error from someone who might be using your code.