Thanks for quick response. I would prefer a fix of logging where we do not have to alter your plugin. Since that exposes us to 'own' to any future problems caused by the sugarchimp addon.
So for the next release if you where to be so kind to add something like the following where you ask me to add return. That would be super. :)
if ( SugarConfig::getInstance()->get('sugarchimp.disable_logging', false) ) return true;
display_errors is off is production. Exception handling however can be tricky. Uncatched fatal error during save kills the execution and opens up for data-loss. And someone can have registered their own error handler bypassing php default and voiding settings of error_reporting. With so many plugins in the eco-system its hard to know.
Its the unknown situations that are hard to test for, the human aspect of software development and its OK but unfortunate. You can use set-error-handler where execution of your code starts and then restore_error_handler to revert to previous error handler for the production scenario. Its the data-loss / failure to trigger business logic that creates dangerous real-world complications.
Its less than optimal and would require your code respect the children of SugarException / SugarApiException. You probably should implement dynamic exception handling with some registry for everyone to register their own custom errors. That should probably be as a shared library on the Sugar Outfitters level.
And of-course it would open up for new unknown problems.But maybe improving the robustness and test-ability of the code. You want fatal to be respected and killing the execution but you only want this when its really a fatal such as business condition not fulfilled.