info/php-the-right-way
1
0
Fork 0
mirror of https://github.com/codeguy/php-the-right-way.git synced 2025-08-31 00:59:53 +02:00
Code Issues Projects Releases Wiki Activity

Style consistency Round 2

Browse Source 
- spacing of jekyll tags at top of file
- line wrap at 120 chars
- url/link verification and move to bottom and order
This commit is contained in:
jrfnl
2014-12-08 05:16:00 +01:00
parent 3f66f074d5
commit 87202921c7
33 changed files with 565 additions and 399 deletions
Download Patch File Download Diff File Expand all files Collapse all files

47
_posts/09-03-01-Exceptions.md
View File

@@ -1,24 +1,25 @@
---
isChild: true
anchor: exceptions
anchor: exceptions
---
## Exceptions {#exceptions_title}
Exceptions are a standard part of most popular programming languages, but they are often overlooked by PHP programmers.
Languages like Ruby are extremely Exception heavy, so whenever something goes wrong such as a HTTP request failing, or
a DB query goes wrong, or even if an image asset could not be found, Ruby (or the gems being used) will throw an
exception to the screen meaning you instantly know there is a mistake.
Exceptions are a standard part of most popular programming languages, but they are often overlooked by PHP programmers.
Languages like Ruby are extremely Exception heavy, so whenever something goes wrong such as a HTTP request failing, or
a DB query goes wrong, or even if an image asset could not be found, Ruby (or the gems being used) will throw an
exception to the screen meaning you instantly know there is a mistake.
PHP itself is fairly lax with this, and a call to `file_get_contents()` will usually just get you a `FALSE` and a warning.
Many older PHP frameworks like CodeIgniter will just return a false, log a message to their proprietary logs and maybe
let you use a method like `$this->upload->get_error()` to see what went wrong. The problem here is that you have to go
looking for a mistake and check the docs to see what the error method is for this class, instead of having it made extremely
obvious.
PHP itself is fairly lax with this, and a call to `file_get_contents()` will usually just get you a `FALSE` and a
warning.
Many older PHP frameworks like CodeIgniter will just return a false, log a message to their proprietary logs and maybe
let you use a method like `$this->upload->get_error()` to see what went wrong. The problem here is that you have to go
looking for a mistake and check the docs to see what the error method is for this class, instead of having it made
extremely obvious.
Another problem is when classes automatically throw an error to the screen and exit the process. When you do this you
stop another developer from being able to dynamically handle that error. Exceptions should be thrown to make a developer
aware of an error; they then can choose how to handle this. E.g.:
Another problem is when classes automatically throw an error to the screen and exit the process. When you do this you
stop another developer from being able to dynamically handle that error. Exceptions should be thrown to make a
developer aware of an error; they then can choose how to handle this. E.g.:
{% highlight php %}
<?php
@@ -47,28 +48,30 @@ finally
### SPL Exceptions
The generic `Exception` class provides very little debugging context for the developer; however, to remedy this,
it is possible to create a specialized `Exception` type by sub-classing the generic `Exception` class:
The generic `Exception` class provides very little debugging context for the developer; however, to remedy this, it is
possible to create a specialized `Exception` type by sub-classing the generic `Exception` class:
{% highlight php %}
<?php
class ValidationException extends Exception {}
{% endhighlight %}
This means you can add multiple catch blocks and handle different Exceptions differently. This can lead to
the creation of a <em>lot</em> of custom Exceptions, some of which could have been avoided using the SPL Exceptions
provided in the [SPL extension][splext].
This means you can add multiple catch blocks and handle different Exceptions differently. This can lead to the
creation of a <em>lot</em> of custom Exceptions, some of which could have been avoided using the SPL Exceptions
provided in the [SPL extension][splext].
If for example you use the `__call()` Magic Method and an invalid method is requested then instead of throwing a standard
Exception which is vague, or creating a custom Exception just for that, you could just `throw new BadMethodCallException;`.
If for example you use the `__call()` Magic Method and an invalid method is requested then instead of throwing a
standard Exception which is vague, or creating a custom Exception just for that, you could just
`throw new BadMethodCallException;`.
* [Read about Exceptions][exceptions]
* [Read about SPL Exceptions][splexe]
* [Nesting Exceptions In PHP][nesting-exceptions-in-php]
* [Exception Best Practices in PHP 5.3][exception-best-practices53]
[splext]: /#standard_php_library
[exceptions]: http://php.net/language.exceptions
[splexe]: http://php.net/spl.exceptions
[splext]: /#standard_php_library
[exception-best-practices53]: http://ralphschindler.com/2010/09/15/exception-best-practices-in-php-5-3
[nesting-exceptions-in-php]: http://www.brandonsavage.net/exceptional-php-nesting-exceptions-in-php/
[exception-best-practices53]: http://ralphschindler.com/2010/09/15/exception-best-practices-in-php-5-3