I have seen that it occurs with every db query, not only if a component failed to install completely. if a $db->execute failed you will see the full query which failed on the error page.

Perhaps it should be an addition to these PRs:
https://github.com/joomla/joomla-cms/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Aalikon+handle+db+in%3Atitle

@alikon What do you think?

There is actually already a try/catch block. But it is around the full query building (https://github.com/joomla/joomla-cms/blob/staging/components/com_content/models/article.php#L84-L242).
And it just shows the error message from the exception. So it doesn't help much.

I think better would be to just try/catch https://github.com/joomla/joomla-cms/blob/staging/components/com_content/models/article.php#L159 and raise a generic error message there.

Bakual, yes I think so. It should only show the query, which provokes an error if Joomla is set to report errors. Else it should tell that there is an error but not the db query to any user entering the page if error reporting is off.

The prefix for a db table for example is an additional security part. Else I could continue to use jos_. But just my opinion.

Actually, it should never show the query.
You can always set up the logger to log the database errors to a log file.

The prefix for a db table for example is an additional security part. Else I could continue to use jos_. But just my opinion.

It's both, a security part but also a feature which allows to have multiple Joomla installations within the same database.

@roland-d
i think should be try/cathed
@Bakual
i was playing around alikon@d533b96

may i have a some feedback....

Just want to remember some arg from this post: #6591

@alikon will propose a pull request and we can then test his solution.

@alikon @rolandd was a PR created?

I haven't seen or heard anything. Any update @alikon ?

Sorry guys, completely forgotten, hope can i have a look on weekend...
On 7 Jun 2016 9:38 pm, "RolandD" notifications@github.com wrote:

I haven't seen or heard anything. Any update @alikon
https://github.com/alikon ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#7428 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AALFsWjcAKQLaJLRnE1v7nvI8--rpcJeks5qJci_gaJpZM4FXYir
.

Thanks

On 8 June 2016 at 07:42, Nicola Galgano notifications@github.com wrote:

Sorry guys, completely forgotten, hope can i have a look on weekend...
On 7 Jun 2016 9:38 pm, "RolandD" notifications@github.com wrote:

I haven't seen or heard anything. Any update @alikon
https://github.com/alikon ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7428 (comment)
,
or mute the thread
<
https://github.com/notifications/unsubscribe/AALFsWjcAKQLaJLRnE1v7nvI8--rpcJeks5qJci_gaJpZM4FXYir

.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#7428 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABPH8dQfNDlNsp-5T3JEKMhgCeezBaAtks5qJmRsgaJpZM4FXYir
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

some works was already done see #8130
not sure if we want to not display the query (for example if error_reporting was setted to none)
any comments?

My suggestion is that now that the database drivers throw a specific JDatabaseExceptionExecuting object on a query failure, the query should be removed from the Exception message and attached to the Exception object as a new property (a downstream catcher of the Exception could access the query via $exception->getQuery();). It removes the need to reverse parse the table prefix out of the query, makes it so that the query is NOT displayed as part of the error message, but continues to make that data available in all required contexts.

There's really no reason the query needs to be attached to the main Exception object's error message.

@mbabker with #10801 plus some changes on https://github.com/mbabker/joomla-cms/blob/e0aa0ec5c8588cd2a74a0489466f7e811a424e7c/libraries/joomla/database/driver/postgresql.php#L1516 function getErrorMessage() we can do the job, i'm right ?

getErrorMessage() should be deprecated and removed. There's no reason to reverse parse the table prefix out of the query if it's attached to the Exception object as a different parameter and not the main message.

do you mean something like this #10949 ?

As we now have a PR I am closing this here so conversation is in only one place