我有一个应用程序,它依赖于一个SOAP服务器来生成内容。此外,对站点的身份验证基于单独的LDAP服务器。显然,如果其中任何一个出现问题或无响应,则站点将出现故障。
我正在尝试设计一种方案,以便为站点管理员提供错误报告,并在站点崩溃时向用户提供良好的提示信息。错误报告实际上只是一个电子邮件、数据库插入或PHP $_COOKIE、$_SERVER、$_SESSION、$_REQUEST以及可能的SoapFault异常的服务器文本文件日志记录。如果发生任何潜在的站点问题,这些信息将帮助我进行调试。
目前,我的站点设计如下:
从上面的糟糕图表 :-) 我有一个类客户端,它包含了所有的try catch块用于soapfault异常,并想知道在catchs中做两件事的最佳方法: 1. 通知用户操作失败(我所有的功能都在if / else块中,如果我确定操作失败,我会将用户重定向到状态页面并告诉他们他们的操作失败了。 2. 报告情况以进行调试(目前此功能是在状态页面中定义的简单函数,当状态页面获取错误代码时,我们会转储Cookier、Server、Session和Request变量,并将其发送电子邮件给站点管理员。
任何关于此的建议都将不胜感激,或者如果您需要澄清,请询问。
编辑:根据我的网页编程经验,我的应用程序通常会在执行操作的页面上显示用户操作的状态,而不会重定向到其他地方。这是我第一次编写应用程序,对于所有状态消息,都执行用户操作并重定向到单独的页面。我是否应该为自己做法感到遗憾?是否有人认为在具有单个状态页面的所有站点操作或具有报告页面上的类/函数的设计方面存在优点?(我正在考虑状态页面本身的设计以及如何报告错误等。)
我正在尝试设计一种方案,以便为站点管理员提供错误报告,并在站点崩溃时向用户提供良好的提示信息。错误报告实际上只是一个电子邮件、数据库插入或PHP $_COOKIE、$_SERVER、$_SESSION、$_REQUEST以及可能的SoapFault异常的服务器文本文件日志记录。如果发生任何潜在的站点问题,这些信息将帮助我进行调试。
目前,我的站点设计如下:
SoapClientInterface (defines soap functionality)
/ \
|
| implements
|
Client (the client implementing the interface, try/catch blocks on all soap calls here)
/ \
|
| extends
|
Authorization (asserts soap objects returned from server/ requests going to server
are appropriate for the user performing the request)
/ \
|
| extends
|
{all children classes using the soap interface defined on this level}
从上面的糟糕图表 :-) 我有一个类客户端,它包含了所有的try catch块用于soapfault异常,并想知道在catchs中做两件事的最佳方法: 1. 通知用户操作失败(我所有的功能都在if / else块中,如果我确定操作失败,我会将用户重定向到状态页面并告诉他们他们的操作失败了。 2. 报告情况以进行调试(目前此功能是在状态页面中定义的简单函数,当状态页面获取错误代码时,我们会转储Cookier、Server、Session和Request变量,并将其发送电子邮件给站点管理员。
任何关于此的建议都将不胜感激,或者如果您需要澄清,请询问。
编辑:根据我的网页编程经验,我的应用程序通常会在执行操作的页面上显示用户操作的状态,而不会重定向到其他地方。这是我第一次编写应用程序,对于所有状态消息,都执行用户操作并重定向到单独的页面。我是否应该为自己做法感到遗憾?是否有人认为在具有单个状态页面的所有站点操作或具有报告页面上的类/函数的设计方面存在优点?(我正在考虑状态页面本身的设计以及如何报告错误等。)
set_exception_handler
中指定的回调函数。这样,您可以在那里进行所有的日志记录和错误页面的生成。这避免了为了避免“未处理异常”致命错误而将所有内容包装在一个巨大的try/catch块中的情况。 - ircmaxellarray($foo, 'bar')
来调用实例方法,或者使用array('Foo', 'bar')
来调用静态方法...(我尽量避免使用Class::method
回调语法)。您甚至可以使用匿名函数。 - ircmaxell