Page 2 of 2

Posted: Thu Jun 22, 2006 7:13 pm
by alex.barylski
Exceptions are typically used to handle errors that are outside of a programmers domain...

Somewhat like error handling...exceptions are intended to capture system exceptions...

Not sure what one looks like in PHP as I haven't used exceptions there yet...but the idea is you prevent your application from fatally crashing by handling an exception...

In PHP...perhaps you could use an exception to handle using a SQL resource which isn't valid (connection failed, etc)

You cannot use exceptions for handling parsing errors, as these are typically caused by syntactical errors, which do not throw exceptions...but don't quote me on that...PHP might

Going back to the SQL connection example...you could also just use traditional if/else type checks on your data, but the idea behind exceptions is also to make error checking less convoluted...

For example, typically, you could check every return value using an IF statement but that would lead to some bloated code, it's easier to wrap an entire section of code inside a try/catch block and when something chokes...have a single exception handler deal with the problem instead of 10 if/else statements...

This has the negative side effect of not being able to always determine *what* exactly went wrong, whereas if/else checks you can print error information specific to exactly what went wrong...

Exceptions, as I've already said (although I can't think of an example in PHP) are useful in catching system generated errors...

For instance in C++ you often use exceptions when dealing with pointers...

Checking that every single pointer is valid would be over kill, but a NULL pointer will almost certainly choke your application...wrapping your pointers up in a single try/catch could possibly allow your application to recover somewhat and atleast give a warning, allow your users to make nessecary changes and exit and try again...

HTH

p.s-This is post 1,000 I do believe :)

Cheers :)

Posted: Thu Jun 22, 2006 9:04 pm
by feyd
I use exceptions for all errors now, even standard level php ones (by catching them via their error handler and throwing them into an exception.)

Here's a snip from a piece of code I wrote not too long ago:

Code: Select all

/**
	 *	<summary>
	 *	<para>Set the recipe -- template -- for the baker -- templator --.</para>
	 *	<param name="aFile">
	 *	A readable, local file name. If the file hasn't changed since last given
	 *	a recipe, we won't need to do further processing, saving a bit of work.
	 *	</param>
	 *	<exception ref="BadRecipeException">
	 *	When the file isn't readable.
	 *	</exception>
	 *	<remarks>TODO: function isn't done yet.</remarks>
	 *	</summary>
	 */
	public function recipe($aFile)
	{
		if (!empty($aFile) and is_file($aFile))
		{
			if (!is_readable($aFile))
			{
				throw new BadRecipeException($aFile, BadRecipeException::READ);
			}
			
			$sha = sha1_file($aFile);
			if ($this->hash != $sha)
			{
				$this->hash = $sha;
				$this->recipe = file_get_contents($aFile);
				$this->dough = null;
				$this->kneed();
			}
			$this->bread = null;
		}
	}

Posted: Thu Jun 22, 2006 9:34 pm
by bg
So, when an exception is thrown, execution stops and php outputs an error?

And when would it be beneficial to use a try block?

And just a random question, whats the xml for in your code block? vi like summary deal?

Posted: Thu Jun 22, 2006 9:41 pm
by feyd
bg wrote:So, when an exception is thrown, execution stops and php outputs an error?
Execution will halt and drop out to the closest catch. If no catch is found, php itself will raise the exception to the exception handler, which will, by default, halt the script and show it to you.
bg wrote:And when would it be beneficial to use a try block?
When you want to catch exceptions from that block.
bg wrote:And just a random question, whats the xml for in your code block? vi like summary deal?
It's a variant (very minor changes) of C#'s XML documentation format. I prefer it over say, phpDocumentor, style for the ease of parsing and I have no issues in reading it. Others may and that's fine.

Off-Topic: apidoc generation

Posted: Fri Jun 23, 2006 5:11 am
by timvw
feyd wrote:It's a variant (very minor changes) of C#'s XML documentation format. I prefer it over say, phpDocumentor, style for the ease of parsing and I have no issues in reading it. Others may and that's fine.
And do you have an XSLT to go with that? (Eg: one to feed ndoc ?)

Posted: Fri Jun 23, 2006 9:31 am
by Oren
Some more information about exceptions: http://www.zend.com/php5/articles/php5-exceptions.php

Re: Off-Topic: apidoc generation

Posted: Fri Jun 23, 2006 9:43 am
by feyd
timvw wrote:And do you have an XSLT to go with that? (Eg: one to feed ndoc ?)
The idea is to have transforms, XSLT or otherwise, into multiple formats. The chief ones I'm concerned about are PDF, HTML and TeX. Although I've been thinking of adding man support too now that I have regular access to it. Right now, I'll assume a transform to NDoc wouldn't be too difficult.

But I digress a bit.


Here's what I'll say about exceptions:
If you're into doing things the "OOP way," using exceptions is the way to go. At minimum you're using abstraction and a unified interface for handling your errors, reducing the need for crazy if() checks and simplifying a lot of things. However, they do not come free. There is a processing cost to having exceptions, it's not much, but it is there. Returning error codes is pretty easy to confuse -- What was code 81352? What?! I have two of them? -- as opposed to exceptions where it's a class, it stores many details inside itself about the error -- what file, what line, possibly a message from the code -- plus, to know what exception it is, all you have to do is ask for it's class name: get_class()