user_error() helps force better checks, rather than waiting for something to break. Take, for example:
```
try {
	$object->UniqueFieldA = randomValue();
	$object->UniqueFieldB = $userValue; // matches $OtherObject's UniqueFieldB
	$object->write();
} catch (Exception $e) {
	// Make generic validation/error message
}
```
I'm sure you'd agree this is bad way of ensuring uniqueness. Yes, some people will use it properly. Sadly, most won't instead using it for things like this, or just hiding database errors they don't want to deal with.

If you need a fallback, you can stick a catch(Exception) right at the end. Having a database (and then, it should really be a connection/syntax/validation/etc) exception means you can provide specific code.

The only real place where databaseError() should be recoverable is during the installer. The installer currently gets around this by the likes of requireDatabaseServer(), which (silently) makes sure connections work. Anywhere else, connection errors aren't something you can recover from so shouldn't be treated like they are.

I'm done going through this for now. Will continue again tomorrow :)

On 4/04/2013, at 4:53 PM, Damian Mooyman <notifications@github.com> wrote:

>> +	 * @todo hook this into a more well-structured error handling system.
>> +	 * @param string $msg The error message.
>> +	 * @param integer $errorLevel The level of the error to throw.
>> +	 */
>> +	protected function databaseError($msg, $errorLevel = E_USER_ERROR) {
>> +
>> +		// try to extract and format query
>> +		if (preg_match('/Couldn\'t run query: ([^\|]*)\|\s*(.*)/', $msg, $matches)) {
>> +			$formatter = new SQLFormatter();
>> +			$msg = "Couldn't run query: \n" . $formatter->formatPlain($matches[1]) . "\n\n" . $matches[2];
>> +		}
>> +		
>> +		if($errorLevel === E_USER_ERROR) {
>> +			// Treating errors as exceptions better allows for responding to errors
>> +			// in code, such as credential checking during installation
>> +			throw new Exception($msg);
> 
> Could you please elaborate on why it's horrible? Why is user_error preferable to using Exceptions? I admit I don't understand your reasoning.
> 
> I could agree with the argument around making a DatabaseException instead of a generic one, but what happens if you need to do something in a try-catch block with a fallback? Should the entire install process spit out uncatchable errors when checking login credentials?
> 
> There is no attempt to hide actual errors here, simply to provide a means of handling them when errors may occur during normal execution of code.
> 
> I appreciate your thorough feedback by the way. :)

---
Simon Welsh
Admin of http://simon.geek.nz/