Jochem Maas wrote:
Gerard Samuel wrote:
Just bouncing a thought on you.
I currently have a default exception handler setup.
So far in the code, I throw an exception when something is wrong.
i.e. Missing file, invalid argument, failed db connection etc...
My thought was centering around if I still needed to use
try/catch in the code, since I have a default exception handler.
Normally, I would rethrow exceptions for it to bubble back up to the top,
where its caught, and something useful done with the stack.
So I removed all try/catch blocks, and its seems to be working as it should be.
Just wondering if there may be an "gotchas" with this chain of thought.
Or should I keep the try/catch blocks as it is???
I think you should leave them in. the idea behind the default exception handler is
to catch uncaught exceptions - uncaught exceptions should be the exception
rather than the rule.
also you don't have to rethrow exceptions, sometimes its very useful to just
catch (possibly ignore) and continue execution just past the catch block.
http://be.php.net/manual/en/function.set-exception-handler.php
<the gotcha>
tha manual states that execution stops after the exception handler in called,
which is fairly limiting.
</the gotcha>
Another way to look at it would be to specify that all 'pages' are based on the following:
try {
// global include
// process some stuff
// do output
} catch (Exception $e) {
// error - show 404 or something?
}
another thing about exceptions, you can be very specific about catching, also the catches can be 'stacked':
try {
} catch (DBException $e) {
} catch (UnknownObject $e) {
} catch (Exception $e) {
}
this implies that the code uses user defined Exception subclasses. i.e. you can write your own Exception classes that you can throw around :-)
I understand what you're getting at. Let me describe a little more of my setup. All requests go through the framework's index.php, where I used to have something like what you described ->
<?php
try
{
// code for page
}
catch(Exception $e)
{
// Log exception
// Display pretty error page with stack
die;
}?>
The problem with this, is that its possible for the logging mechanism,
to throw an exception, leaving the exception not logged, along with the default *ugly*
page.
So thats when I decided to start using the default exception handler.
Currently, I have the default exception handler, log the exception,
and display a *pretty* page.
If the logging mechanism does throw an exception, the exception will not
be logged, but at least, the *pretty* page does display.
Your point about page execution stopping after the default exception handler is
called, is acceptable for me.
From my original email ->
So far in the code, I throw an exception when something is wrong.
i.e. Missing file, invalid argument, failed db connection etc...
What I mean by this is that if the code sees that there is no other
way to go, to throw an exception.
With the setup Im currently using, I should still be able to use exceptions to
control execution flow, as long as they are tried/caught properly.
As I understand it, exceptions can be used to
a) Handle errors
b) Control execution flow
Right now, Im only concerned about a).
Hopefully that makes my situation a bit clearer.
So with this in mind, the default exception handler, handles
the *pretty* error page, and tries to log the exception.
And I remove all try/catch blocks from the framework code (the reason for this email).
Then in the application, that runs on top of the framework, then I
can use try/catch to control code execution.
I hope that was clearer. If I've missed the point, feel free to bash me in my head ;).
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
