First in what I do, the point of an exception is to cause a program to terminate, with a message made available (in a log, email, or on STDERR) that will give a programmer somewhere to start in fixing the problem. If that is the point, then creating an object is extra overhead that obscures what you're trying to do. Therefore for this specific scenario, creating an object is worse than just creating the message that you want to see logged. Because even though the effect may be the same, you obscured what was going on.

In the worst case, your error handler has a mistake and you don't successfully generate an object! Yes, we should all have tests. But reality is that our error checking code tends to be the least tested, and therefore should be coded in the most simple and straightforward way possible. It is harder to not notice messing up a string than a method call, so strings are to be preferred.

Now let's go on to the point that I initially made.

In general when I see exception objects being created, my expectation is that someone is intending to catch those objects and process them in interesting ways. Now sometimes that might be appropriate. For instance if you want to display messages in a language-localized fashion. Or if you need to display messages after postprocessing in various ways (text message for a command line, popup for a GUI, HTML for a web form). However it is not appropriate for what I'm doing. Which raises the question of why they are being used.

Now, as I said, I think that just constructing the final message is better because it is more straightforward. However what some people like to do is use exceptions as a general flow of control mechanism. Yes, I know that they have the capability of doing so - else they wouldn't be useful. But when people start using exceptions that way, you get into problems. Some people dislike that in all circumstances. I'm not entirely convinced of that, though I dislike the action at a distance. But the fragility of eval, $@ and die in Perl causes me to be particularly suspicious of the design idea because I know how easy it would be to just swallow exceptions rather than doing something useful with them.

And a random point on the topic. Re: Re2: Learning how to use the Error module by example mentions specific problems with one module that tries to make exception handling cleaner in Perl. I have no idea whether others are prone to the same kinds of issues, but unless I'm given some concrete benefits, it isn't worth my energy to find out.