Swiftmailer doesn't touch any configuration that's responsible for showing errors. Among the recommendations for production servers is to have display_errors = Off
and display_startup_errors = Off
, which can be set in php.ini
, httpd.conf
, .htaccess
, .user.ini
, etc, or even using ini_set()
. You should make sure these directives are correctly set.
I'm not familiar with how Laravel handles exceptions and errors, but it looks like the Swift_TransportException
is thrown outside of Laravel's error-handling process. Can you point out where in the flow of the application the exception is thrown? Maybe a stack-trace?
PS: Just a tip: Things like sending emails are better not done during a request at all. You could offload it to some sort of queue, and have another process on the server handle it. You could take a look at Gearman for this.
update
Looking at the stack-trace, it seems Laravel does catch the exception because Log::exception();
is invoked (in application/config/error.php
line 91). But the trace doesn't reveal how it got there. Maybe you can run it on a development machine where you have Xdebug installed. Xdebug will give you a more precise stack-trace when the exception is throws, ending with public/index.php
(where the request started).