The “dynamic call group” is for everything concerning “calling” methods and functions; the “logic group” is useful for problems inside the parameter list; and the “runtime group” is for everything happening inside the method/function body?

Example of autoloading in PHP

I’ve adapted the User-guide’s tutorial and currently have two Controllers connected(1 controller to 1 table) to two related tables in my db(MySQL), implementing the Table Data Gateway pattern. Any advice on how to do joins?

Thanks

SPL in general is good stuff – and SPL exceptions is a good idea, but due to missing examples, missing explanations on php.net and its ambiguity there is little acceptance in the PHP community and each exception is used with a different understanding in its meaning, depending on which developer is using it. Now after some years there is still no big adaptation of SPL exceptions in the PHP community.

These issues are the reason why i elate team mates to write own exception classes. I know they are able to practice “clean code” – strongly believe they do not introduce ambiguity (better than SPL).

Next issue i want to outline is: exceptions are part of your API.
So use doc blocks to your methods and add @throws annotations for each exception thrown. When your method uses external code (other objects, external libs) the external exceptions would bubble through your method. External exceptions become part of your API this way. Every change to the external code (rename of an exception or introduction of a new exception) would require you to update your doc block, too. It is not a good idea to add these external exceptions to your API (to your doc block with additional @throws lines). If your method can not recover this exception it should re-throw it as your own exception at least. Do not forget to add a catch-all statement (PHP base exception) and re-throw your own exception . When doing this you are immune for external changes – you follow the open-closed principle. If your app is for PHP >=5.3 use nested exceptions when re-throw an exception.

Your argument, that standardized exceptions would enable you to switch from one lib to another – i can not follow.
To be able to switch from one lib to another lib without changing my code requires the following:
a) two libs that implements the same interfaces
b) two libs that offers same external behavior
c) two libs that throws the same exceptions within the same event

There is no kind of “interfaces with exceptions declaration” in PHP that can be used to keep a consistent API.
SPL is trying to solve this by convention – but you can not solve this by convention, because you can imagine an infinity amount of problem domains – and good exception names that fits to that problem domain are available in infinity amount, too.

Do not misunderstand me: i elate my team mates to follow conventions. There are a lot of conventions that do make sense. E.g. getter and setter methods which names are prefixed with “get” and “set”. Factory methods that are postfixed with “Factory”, etc. But trying to provide a convention (lib) with e.g. 200 getter names will never be enough. If there is a need for a naming convention then contribute this to a wide-used coding standard.

PHP do need a kind of “interfaces with exceptions declaration” to define the “full” API.

The only point that should be discussed in further detail is: Does it make sense to promote to categorize your exceptions into “runtime exception” or “logical exception”? I do not have a standpoint for that today, but i will think about it. But again, i do not see a reason why this should be introduced by a lib. Promote coding standards or best practices for that, would be a better way of doing that.

Another point i want to propagate: do not use exceptions with exception-codes. Codes requires mental mapping which is bad style / old school (see “clean code” for details).