Error handling

[Ed Lazor-3]

Is it best to create your own exception classes and build them with
built-in logging or do you recommend a different approach?  I'm
noticing that the zend exception classes are all empty - is that
because they're just used to define different types of exceptions?

-Ed

[Jeroen Keppens]

Typically when you catch exceptions, you can check on the class type.  
You usually don't check on the message. So empty classes, provide the  
possibility for different messages for the same type of exception,  
while retaining the option to check for the type of exception.

try {
    // Code
} catch (My_Db_Exception $e) {
     // Bla bla
} catch (My_File_Exception $e) {
     // Bla bla something else
} catch (Exception $e) {
     // Default bla bla
}

If you have something specific you want to check on, make it into a  
separate class.

Wkr
Jeroen

On 01 Jul 2009, at 23:06, Ed Lazor wrote:

> Is it best to create your own exception classes and build them with
> built-in logging or do you recommend a different approach?  I'm
> noticing that the zend exception classes are all empty - is that
> because they're just used to define different types of exceptions?
>
> -Ed
>

On Wednesday 01 July 2009 23:06:31 Ed Lazor wrote:
> Is it best to create your own exception classes and build them with
> built-in logging or do you recommend a different approach?  I'm
> noticing that the zend exception classes are all empty - is that
> because they're just used to define different types of exceptions?

That's right, because exception classes don't handle the exceptions
themselves, they're passed to the code that does.

--
Dado

[Ed Lazor-3]

So where would you handle your logging if not from with a base
exception class?  Are you including the logging as part of the "// Bla
blah" part that you have listed below?



On Wed, Jul 1, 2009 at 2:14 PM, Jeroen Keppens<[hidden email]> wrote:

> Typically when you catch exceptions, you can check on the class type. You
> usually don't check on the message. So empty classes, provide the
> possibility for different messages for the same type of exception, while
> retaining the option to check for the type of exception.
>
> try {
>   // Code
> } catch (My_Db_Exception $e) {
>    // Bla bla
> } catch (My_File_Exception $e) {
>    // Bla bla something else
> } catch (Exception $e) {
>    // Default bla bla
> }
>
> If you have something specific you want to check on, make it into a separate
> class.
>
> Wkr
> Jeroen
>
> On 01 Jul 2009, at 23:06, Ed Lazor wrote:
>
>> Is it best to create your own exception classes and build them with
>> built-in logging or do you recommend a different approach?  I'm
>> noticing that the zend exception classes are all empty - is that
>> because they're just used to define different types of exceptions?
>>
>> -Ed
>>
>
>

[Jeroen Keppens]

Your "error handler" takes care of handling (and also logging) the  
error.

The exception itself typically has no logging, it's your app that  
takes care of it.

Wkr
Jeroen

On 01 Jul 2009, at 23:34, Ed Lazor wrote:

> So where would you handle your logging if not from with a base
> exception class?  Are you including the logging as part of the "// Bla
> blah" part that you have listed below?
>
>
>
> On Wed, Jul 1, 2009 at 2:14 PM, Jeroen Keppens<[hidden email]
> > wrote:
>> Typically when you catch exceptions, you can check on the class  
>> type. You
>> usually don't check on the message. So empty classes, provide the
>> possibility for different messages for the same type of exception,  
>> while
>> retaining the option to check for the type of exception.
>>
>> try {
>>   // Code
>> } catch (My_Db_Exception $e) {
>>    // Bla bla
>> } catch (My_File_Exception $e) {
>>    // Bla bla something else
>> } catch (Exception $e) {
>>    // Default bla bla
>> }
>>
>> If you have something specific you want to check on, make it into a  
>> separate
>> class.
>>
>> Wkr
>> Jeroen
>>
>> On 01 Jul 2009, at 23:06, Ed Lazor wrote:
>>
>>> Is it best to create your own exception classes and build them with
>>> built-in logging or do you recommend a different approach?  I'm
>>> noticing that the zend exception classes are all empty - is that
>>> because they're just used to define different types of exceptions?
>>>
>>> -Ed
>>>
>>
>>

[weierophinney]

-- Ed Lazor <[hidden email]> wrote
(on Wednesday, 01 July 2009, 02:34 PM -0700):
> So where would you handle your logging if not from with a base
> exception class?  Are you including the logging as part of the "// Bla
> blah" part that you have listed below?

Your ErrorController::errorAction() is a good place for such activities.
:)

> On Wed, Jul 1, 2009 at 2:14 PM, Jeroen Keppens<[hidden email]> wrote:
> > Typically when you catch exceptions, you can check on the class type. You
> > usually don't check on the message. So empty classes, provide the
> > possibility for different messages for the same type of exception, while
> > retaining the option to check for the type of exception.
> >
> > try {
> >   // Code
> > } catch (My_Db_Exception $e) {
> >    // Bla bla
> > } catch (My_File_Exception $e) {
> >    // Bla bla something else
> > } catch (Exception $e) {
> >    // Default bla bla
> > }
> >
> > If you have something specific you want to check on, make it into a separate
> > class.
> >
> > Wkr
> > Jeroen
> >
> > On 01 Jul 2009, at 23:06, Ed Lazor wrote:
> >
> >> Is it best to create your own exception classes and build them with
> >> built-in logging or do you recommend a different approach?  I'm
> >> noticing that the zend exception classes are all empty - is that
> >> because they're just used to define different types of exceptions?
> >>
> >> -Ed
> >>
> >
> >
>

--
Matthew Weier O'Phinney
Project Lead            | [hidden email]
Zend Framework          | http://framework.zend.com/

[Michael Irey]

Matthew Weier O'Phinney-3 wrote:

-- Ed Lazor <[e-mail]> wrote
(on Wednesday, 01 July 2009, 02:34 PM -0700):
> So where would you handle your logging if not from with a base
> exception class?  Are you including the logging as part of the "// Bla
> blah" part that you have listed below?

Your ErrorController::errorAction() is a good place for such activities.
:)

--
Matthew Weier O'Phinney
Project Lead            | [e-mail]
Zend Framework          | http://framework.zend.com/

Michael Irey wrote:

I agree you should have have logging in the ErrorController::errorAction() if you want to, however what if you want to log exceptions that end up getting caught.

There are 2 options as I see it, option 1 will only log exceptions that are caught, which never ends up happening anyways because the whole zf application is essentially wrapped in a try/catch block. Option 2 however will provide logging for Exceptions regardless of whether they are caught or not.

Any feedback on these 2 options would be appreciated.

Option 1:

function exception_handler($exception) {
  // Do logging stuff here
}

set_exception_handler('exception_handler');

throw new Exception('Uncaught Exception');


-- or --

Option 2:

class BaseException extends Exception
{
    public function __construct($message, $code = 0) {
        // Do logging stuff here
   
        parent::__construct($message, $code);
    }

}

class MyCustomException extends BaseException {}


try {
    // if something happened
    throw new MyCustomException('This Exception get caught');
}
catch (Exception $e) {
    // handle the exception here, and this will automatically get logged.
}

[umpirsky]

try {

// do sth

} catch (Exception $e) {

// do sth

Your_Logger::error($e);

}

Regards,
Saša Stamenković

On Wed, Jul 1, 2009 at 11:06 PM, Ed Lazor <[hidden email]> wrote:

Is it best to create your own exception classes and build them with
built-in logging or do you recommend a different approach?  I'm
noticing that the zend exception classes are all empty - is that
because they're just used to define different types of exceptions?

-Ed

[Carlton Gibson-2]

Some javascript/style in this post has been disabled (why?)

On Wed, Jul 1, 2009 at 11:06 PM, Ed Lazor <[hidden email]> wrote:

Is it best to create your own exception classes and build them with
built-in logging or do you recommend a different approach?  I'm
noticing that the zend exception classes are all empty - is that
because they're just used to define different types of exceptions?

-Ed

There was a good piece on this in CodeUtopia some time back: 

Handling errors in Zend Framework