通过MVC架构设计的程序的几个层，我发现我希望获得更多关于更深层的方法返回结果的信息，但我并不总是能够预测何时需要这些信息。而且，为了抽象起见，我可能不希望该方法将内容输出到特定于应用程序的日志中（该方法可以在不同的程序中使用），也不希望像上面的其他层那样具有特定的依赖应用程序的行为。
例如，在一个给定的实用程序函数中，在执行一个操作之前，我可能有几个先决条件检查，但都失败了。如果我在其中任何一个上返回false，打电话的人都不知道发生了什么。如果我返回false并将发生的事情记录到应用程序日志中，那么我将该函数绑定到特定于应用程序的行为。
问题是：实现一个名为MyResult的小类，并让它返回响应状态（ok/false）、一条消息、一个最终的整数代码和一个对象占位符（数组或对象），调用方可以在其中访问返回的对象，这是好的/常见的做法吗？这个MyResult类将在整个系统中使用，并且将是所有方法及其调用者之间的通用"方言"。然后，所有方法都将始终返回MyResult的一个实例。
你能举个例子吗？这看起来有点像，但我可能错了，你有静态使用的方法（即使它们没有像以前那样实现/调用）。可以自行绘制的表对象的基本示例称为：$myTable->paint();。它可以返回一个变量（true/false），但任何其他事情（如日志记录）都是table()的函数，就我而言，无论是调用方法还是返回值都不应该与此有关。
也许我很难理解你将在什么情况下使用它，但如果你想出于某种需要消息（或事件等）的目的发送消息，你应该定义它们，但我认为定义默认的returnObject来传递方法调用结果没有任何好处。
对于错误，您有两种选择：异常（即：您确实不希望发生的事情，应该停止执行）和错误：预期但不需要的行为。第一个应该单独处理，第二个可能很棘手，但我认为对象本身应该包含一个状态，它可以清楚地表明发生了什么。
这就是例外情况。你不必像Java那样过度处理它们，但它们的存在是因为错误代码很糟糕。
如果一个框架没有提供您需要的特定功能，那么就没有其他方法可以让您自己处理了。特别是如果你需要一些与框架目标背道而驰的东西，那么永远不会成功。
然而，许多框架都提供了可以扩展它们的地方。有些人比其他人更灵活。因此，如果可能的话，我会看看你是否仍然可以将你需要的功能作为一种插件、插件或辅助代码来实现，这些代码可以留在框架中。
如果这不可能，我想说，做任何你想做的事情都是有效的。使用框架中对你有用的部分。