Erin,
Completely depends on the type of error. Are you talking about a PHP error?
Typically what you try to do is think of all possible ways that something could work out. And you have a fall back plan.
It may be that the fall back plan is to return nothing. There is no problem with doing that.
In the case of the template parser some cases trigger the no_result function which alternately displays a 404 page (among other actions) depending on various conditions.
In some cases, especially with plugins, you want to return the tag_data unaltered if the plugin can’t do anything because it’s conditions aren’t met.
In some cases you want to return an empty result instead.
In some cases its good to output an error message of some kind especially if the problem is a direct result of something a user did or didn’t do.
You have two ways of doing that built in using the Output class:
$OUT->function fatal_error('SOMETHING BAD HAPPENED!!!');
or
$messages = array('Error 1', 'Error 2');
$OUT->show_message($messages);
In the cases above the error display halts the execution of your script and gives the person an error page. Sometimes you don’t want that either so instead you return a message that just displays in its place in the template along with the regular flow of the page.
It all really depends on what you need for a given situation.
Generally though, especially with plugins I try to make sure no PHP errors happen. Instead I deal with the possibilities in the code so that it just works. I generally consider a PHP error a mistake on my part and something I need to fix.
Jamie
Derek asked me to clarify the usage of the Output functions.
These should really only be used in direct response to an action a user has taken. And should not generally be used within modules or plugins that affect templates. You don’t want a page to render a big blue error box when a plugin can’t find any text to manipulate.
They are more appropriately used to provide information on validation errors for a user submitted form. Or something along those lines.
Jamie
Packet Tide owns and develops ExpressionEngine. © Packet Tide, All Rights Reserved.