Within the application is where you would need to do precisely what you are wanting, yes.
I'll take a moment to recommend against that, first: It appears that the site is getting enough use that it needs more database connections, and this type of thing may not really be able to be helped overall. (I can only assume, for example, that MediaWiki is not written such that it is needlessly using extra connections than it needs to)
My basic thought here is, if at all possible, try to give the site what it needs to operate. If that would cause trouble with the shared MySQL server, perhaps that bottleneck needs to be addressed. Whether it's a wait or an error, failure to connect to the database will drive a certain number of users from the site, and is just generally creating a negative experience for them.
The 'easy' solution would be to change the error message to be a more friendly one, but that may not address the problems.
Assuming you can not raise the 10-connection limit, the application may need to be altered (and perhaps quite extensively) such that every database connection attempt is wrapped in code which catches failures to connect, waits a pre-determined time, and tries again a certain number of times.
You may be lucky, and MediaWiki may have such functionality in it which can be configured in. Someone more familiar could help with that, if so. Another (more likely) point of lucky-ness would be if the DB access code is very tightly contained, and so this solution would not be a matter of changing 300+ places in the code to do this (a time-consuming and aggravating prospect, to say the least).
I would only recommend such a solution if it is very infrequent that these errors happen. If it's a regular occurrence, it could just end up bringing the site to a crawl, where it's waiting/retrying DB connections constantly... and still ending up returning an error eventually, anyway.