To explain tye's whimsical (musical?) solution, a bit...

If you pass die a string exception that ends in anything other than a newline, Perl will helpfully insert its own message complete with file and line number. If you give it a "\n" like Eliya did, it won't add "Died at file, line", but you will still get the new line.

On the other hand, if you give die an object, Perl will try to stringify the object. Normally, that would result in something noisy like Fart=ARRAY(0x871ff0). However, if you use overload, you can provide your own rule for stringify-ing an object. In tye's example, he stringified it to an empty string, hence silence instead of farts.

My own much less humorous version, gets rid of the extra array creation and encapsulates the blessing and act of dying. It's not as funny, but maybe a bit more practical:

{
  package DieSilently;
  use overload q{""} => sub { '' };
  sub now { die bless(\$_[0],$_[0]) }
}

print STDERR "Hello!\n";
DieSilently->now();
print STDERR "World!\n";

#outputs ($ are the command prompt) 
$ Hello!
$
[download]

You're mildly incorrect. Perl does not automatically stringify your exception objects. It leaves them alone and they're just like a regular objects. tye's object happens to have an overloaded conversion but that's only invoked when you examine it by printing $@ or testing to see if $@ is true/false.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

I'm sorry if I was not exactly precise. A more precise statement would have been "If the exception is not caught, then Perl itself prints it out which has the result of stringifying it. Hence it prints "Fart=ARRAY(0x...)", i.e. the default stringification of a blessed object, if you don't overload it and whatever you overloaded it to do otherwise. That's at least what I see on my machine with Debian Linux/Perl 5.10. Do you see something different?

Now, I hope you will not mind if I offer a slight clarification on your words.

When testing an exception, one cannot assume that it will be stringified. That depends on how one does the test, whether or not overload's "fallback" option is used, and what other operators are overloaded with a custom subroutine. For instance, if one tests by doing if (!$@) and you've overloaded !, then the overload for ! will be invoked, not stringification. If instead you do if ($@), then Perl will first look for an overload for "bool". If you have disabled fallback and you do not define the "bool", operator you will get a complaint "Operation 'bool': no method found". Only if you enable fallback, will it stringify the object to compensate for the missing bool operator definition. See overload for further discussion.

Also, just to be clear, in none of these cases (printing, testing) is the object itself destroyed. The application of the !, bool or "" operators are strictly for evaluation in context. The exception object remains an object before and after.

Thank you for the explanation, very much appreciated.