Page 2 of 2
Re: Exception handling
Posted: Thu Feb 05, 2009 2:45 pm
by rrcatto
Jcart wrote:I've actually never even considered doing it this way. However, I would vote against doing so, considering the exceptions are a subset of the component, and are not components themselves.
A class is a component, by definition.
Consistent naming conventions aid further development and code readability.
I impose very strict naming conventions on myself when developing applications. For instance, in a database, every single field has a unique name throughout the entire database, and strictly follows a standard, e.g. s_id (table prefix underscore field name).
Can you tell me where in the hierarchy of exceptions does BadMethodCallException sit?
And what is the difference between Swift_Exception and Swift_SwiftException?
Re: Exception handling
Posted: Thu Feb 05, 2009 3:09 pm
by Chris Corbyn
I appreciate your feedback, but my Exceptions are namespaced according to the sub-package of the library they are thrown in. This seems more logical than naming them according to their hierarchy and adding confusing namespaces (e.g.):
Swift/Transport/*
Swift/Exception/Transport
I'll I need to is document the flippin' things

Which I am going to do for the new version, I just haven't had the time yet with a major deadline coming up at work.
I would argue that your naming convention is less "consistent" than mine. Mine are named according to the sub-package they belong to (so everything is namespaced more or less following Zend's conventions).
BadMethodCallException is nothing to do with Swift Mailer.... that's a PHP Exception that you're supposed to throw if somebody calls an undefined method. I'm throwing that because it's in a very-specific scenario where somebody tries to call an overloaded method that does not exist.
Re: Exception handling
Posted: Thu Feb 05, 2009 3:55 pm
by rrcatto
Chris Corbyn wrote:I appreciate your feedback, but my Exceptions are namespaced according to the sub-package of the library they are thrown in. This seems more logical than naming them according to their hierarchy and adding confusing namespaces (e.g.):
Swift/Transport/*
Swift/Exception/Transport
BadMethodCallException is nothing to do with Swift Mailer.... that's a PHP Exception that you're supposed to throw if somebody calls an undefined method. I'm throwing that because it's in a very-specific scenario where somebody tries to call an overloaded method that does not exist.
So is the standard naming convention Swift_ChildNameException?
Fair enough re BadMethodCallException.
I'll await your documentation to discover what Swift_SwiftException is.
Re: Exception handling
Posted: Thu Feb 05, 2009 5:37 pm
by Chris Corbyn
rrcatto wrote:Chris Corbyn wrote:I appreciate your feedback, but my Exceptions are namespaced according to the sub-package of the library they are thrown in. This seems more logical than naming them according to their hierarchy and adding confusing namespaces (e.g.):
Swift/Transport/*
Swift/Exception/Transport
BadMethodCallException is nothing to do with Swift Mailer.... that's a PHP Exception that you're supposed to throw if somebody calls an undefined method. I'm throwing that because it's in a very-specific scenario where somebody tries to call an overloaded method that does not exist.
So is the standard naming convention Swift_ChildNameException?
Fair enough re BadMethodCallException.
I'll await your documentation to discover what Swift_SwiftException is.
Swift_SwiftException is just the base Exception in Swift Mailer. It was called Swift_Exception in version 3, it's just renamed that's all
Pretty much I'm preparing for namespaces so some of the names will directly correlate to their namespaced format:
Code: Select all
import Swift;
import Swift::Plugins;
try {
$mailer = new Mailer(new SmtpTransport( ... ));
$mailer->registerPlugin(new AntiFloodPlugin( ... ));
// ... stuff ...
} catch (TransportException $ex) {
// .. error in transport ...
} catch (SwiftException $ex) {
// .. all other errors
}
Using Swift_Exception means that the class name would be "Exception" and would cause conflicts with PHP itself if imported.
NOTE: The above code is PHP 5.3 and we're not ready for that yet, but generally it should be easy to translate all of Swift Mailer to use namespaces like this. This is also why I use names like Swift_Plugins_AntiFloodPlugin instead of Swift_Plugins_AntiFlood, because once you remove the namespace, the class name still makes sense.