Exception overkill?

knowj

I have a custom Exception handler that I use for any system I write. I haven't been working with exceptions for long so alot of if it feeling my way slowly along the route to "best implementation" below is an example of a simple update the thing I don't like though is always checking if something is false.

Is there anything that would be seen as directly wrong with this method?

Is it best to throw an exception after each internal method or would it be better to check once if $stmt->error is populated then throw an exception rather than after every method call?

private function update()
	{
		if (!$stmt = $this->db->prepare("UPDATE `gallery` SET `userId`=?, `title`=?, `image`=?, `thumb`=?, `live`=? WHERE `id`=? LIMIT 1"))
			{
				throw new mException($this->db->error, $this->db->errno);
			}

if (!$stmt->bind_param('isssi', $this->userId, $this->title, $this->image, $this->thumb, $this->live))
	{
		throw new mException($stmt->error, $stmt->errno);
	}

if (!$stmt->execute())
	{
		throw new mException($stmt->error, $stmt->errno);
	}

$stmt->close();
	}

I know there's not very often a direct right/wrong but I appreciate anyone's 2 pence/cents

thanks in advance

Weedpacket

It would I think be better to throw different types of exception for different errors (all subclassed from mException if need be), so that catch blocks can be more discerning about what they catch (e.g., a permission error might be handled differently to a parameter being missing which might be handled differently to a constraint violation).
Another syntax you might like to consider (since none of those statements return anything you're interested in beyond success or failure) is

$stmt = $this->db->prepare("...")
    or throw new mException(/*...*/);

Just less punctuation, and a little less intrusive.

Shrike

I agree with Mr Packet about having different typed exceptions, since that is really what they are designed for. I do however feel that throwing an exception for every line of code is overkill. From the point of view of your calling code, I am saying "update the database and tell me if it worked", I don't really care which part failed, just that it did fail. So the exception should be thrown if $stmt->execute failed.

The reason for typed exceptions is that your update method stands on the shoulders of others, the database connection object may find it's lost the connection and throw a DbConnectionException, but the caller to "update" may want to ignore that and allow it to bubble up to a higher layer.

Edit: reiterating what Weed already said. Ho hum.

knowj

I agree with you both. I need to expand my exceptions into more classes rather than having a single handler.

On the code above then I really only need to capture $this->db errors with one throw and $stmt->errors with another.

On an update query the $stmt->execute() is pretty much the end of the line but in a prepared SELECT statement you bind_results and fetch at what point would it be best to throw an exception in this instance?

Probably worth another thread but is creating an array a lot less resource heavy than creating an equivalent object?

Weedpacket

I think they're about equivalent.

There's the overhead of having a class, but that's a one off cost that's amortised over all instances.

The internal representation of an object has an extra field to specify which class it's an instance of, but that's just a pointer.

Both entities don't store any data themselves, but just consist of lists of pointers to where the data is stored.

Arrays and objects are trivially cast into each other (casting an array into an object results in an object of type stdClass).

Arrays are arbitrarily resizable (to do the same thing with an object (without using any arrays) is an exercise in obfuscation).

Short answer; horses for courses.