* (bug 14497) Throw visible errors in installer scripts when SQL files fail due to...
authorBrion Vibber <brion@users.mediawiki.org>
Thu, 12 Jun 2008 00:15:29 +0000 (00:15 +0000)
committerBrion Vibber <brion@users.mediawiki.org>
Thu, 12 Jun 2008 00:15:29 +0000 (00:15 +0000)
commit6776038c21f61e12aca399be260921db2e3ad7f5
tree1ee3abeaa23a4aac172b3e6127e2849f8ac7de4b
parent140ff5b2fc85c8b84f4fdf9b78d17d9240df78ef
* (bug 14497) Throw visible errors in installer scripts when SQL files fail due to database permission or other error

Database::sourceFile() was suppressing the standard error reporting, and returning any errors as a string value.
While nice behavior in theory, several years ago, this doesn't work well in practice; most callers assume either that any error will be fatal and halt the script (no error checking) or that an error will return false and any boolean true is success. This caused false positive success, as error conditions returned as strings evaluated to true.
Changed to letting the database object's existing erorr reporting behavior control whether it throws an exception or suppresses the error and returns it as a string -- default behavior will be to throw an exception, making 'can't run CREATE TABLE' errors actually visible to the user trying to install an extension.
For good measure, failure to open the input file also throws an exception to ensure that it will produce a nice visible error instead of a hidden WTF.
RELEASE-NOTES
includes/Database.php