[dev] Code/Logic Exceptions vs. Execution Exceptions
Jan Schneider
jan at horde.org
Tue Jan 17 23:27:51 UTC 2012
Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
> Quoting Michael M Slusarz <slusarz at horde.org>:
>
>> Before I throw this into CODING_STANDARDS, wanted to run this by the list.
>>
>>
>> Exceptions in Framework Packages
>> ================================
>>
>> Exceptions thrown in packages can be divided into two categories:
>> code/logic exceptions and execution exceptions.
>>
>> Code/Logic Exceptions
>> ---------------------
>>
>> These are exceptions that should be thrown when there is an issue
>> with the programming logic - e.g. the environment was not properly
>> set up by an application, or a required parameter was not provided.
>>
>> These type of exceptions should throw one of the SPL Exceptions
>> (e.g. BadFunctionCallException, LogicException, RuntimeException),
>> NOT a package exception. This ensures that errors will normally
>> cause a fatal error, rather than potentially being caught and
>> ignored by the calling code. As such, there is no need to document
>> the exception in phpdoc. Further, the exception messages should
>> not be translated, as these messages are intended for developers
>> not users.
>
> Agreed.
>
>> Execution Exceptions
>> --------------------
>>
>> These are exceptions that are thrown due to an error encountered
>> while performing the action requested by the calling code.
>>
>> Any package that throws at least one execution Exception should
>> define a Package_Name_Exception class that extends Horde_Exception.
>> Execution Exceptions should use this class when throwing an error.
>> Any method that throws this kind of exception should document it
>> in the phpdoc using the @throws keyword. These messages should be
>> translated, as they potentially could be displayed to the user at
>> the application level.
>
> Agreed, though I thought at one point we agreed that exceptions that
> would be expected to only make it to a log would not be translated.
Yes, it's a thin line though, because you never know what the
exception consumer is doing with it. When we know, this distinction
should be done.
> Either way, fine with me as long as it's standardized.
Overall +1
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
More information about the dev
mailing list