|
|
Posted by Gerard Samuel on 09/29/74 11:07
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 ;).
Navigation:
[Reply to this message]
|