Exception handling

Swift Mailer is a fantastic library for sending email with php. Discuss this library or ask any questions about it here.

Moderators: Chris Corbyn, General Moderators

rrcatto
Forum Newbie
Posts: 8
Joined: Wed Feb 04, 2009 6:02 pm

Re: Exception handling

Post 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?
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Re: Exception handling

Post 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 :P 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.
rrcatto
Forum Newbie
Posts: 8
Joined: Wed Feb 04, 2009 6:02 pm

Re: Exception handling

Post 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.
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Re: Exception handling

Post 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.
Post Reply