when the grounds break
 

When I used PHP, MySQL, Apache and CakePHP, then something broke, I wouldn't know if it was PHP, MySQL, Apache or CakePHP that broke.

The source code of big projects is huge like nobody knows the whole code. Do you have to know PHP, MySQL, Apache or CakePHP's source code? CakePHP probably has the smallest source code, but even so it's big, because it's a full-stack framework. Do you have to know CakePHP's source code?

When something breaks and you look at the stack trace, you see lots of return statements. If you don't know the whole source code and how the functions interact, how come you know what went wrong?

Your post is quite confusing. I don't really understand what your question is. If you just use LAMP you do not need to understand the code of it's components. If your environment is configured properly then all errors you should see are result of the bugs in your code or bad configuration - which by the way is very well documented. Stack traces are sometimes long, but again, if your LAMP and framework are configured properly they will always point you to the error in your code, reporting entire function call stack - only for your debugging convenience! It's very rare event that application like Apache crashes on it's own. I don't know CakePHP but given it's popularity I doubt that it's unstable product.

You should almost always look first at your own code to determine where something went wrong. Most mature packages like PHP, Apache, etc have very few bugs, and those generally tend to be obscure and affect only unusual cases. Rarely does anything in software 'break' spontaneously. Something changes, usually for some kind of upgrade, which adds or exposes bugs in the code. Always look first at the body of code where change was introduced. Adding changes incrementally, and testing as you proceed is a good way to avoid the possibility of introducing problems whose origins are difficult to ascertain.

As either a programmer or system implementer, it is good strategy to create small modules which can be tested entirely or substantially in isolation (unit testing). When these are confirmed to work properly, they can be added to the larger body of work. Eventually, when all of the individual pieces are known to work, the probability of the whole working correctly should also be high. This is a sort of converse of the divide-and-conquer strategy.

As a system implementer, it is rarely required to look at source code (unless that is the only documentation).

--- rod.