Hi Simon, thanks for your 2c - it's always worth more than that :-) I've inlined some questions/responses below.
On 18 May, 12:29, [EMAIL PROTECTED] wrote: > Graham > > I like both of these suggestions and think they both have a place in > the runtime. > > We should have a separation between Business and System exceptions. We > expect the calling component to care about Business exceptions as the > problem is likely to be their fault. They should be phrased in > business terns and I wouldn't expect that a stack trace is required or > even useful. If you tell me the number I entered is out of range I > don't care which class trapped the problem. > > They care about System exceptions too but they can't do anything about > it so much less detail is required in response. Some note that it has > happened and an indication whether it's terminal or trying again might > succeed. Contact details may also be useful. Again a stack trace is > not required but the exception mush be logged with full info so the > admin can fix it. > I agree that some indication that something has happened and whether it's worth retrying is important. Http has a similar concept with status codes for things like Internal Server Error or Not Implemented vs Service Unavailable. I'm not sure how best to enable this without becoming too prescriptive (e.g. requiring all exceptions to inherit from common base SCA exception. We do have an SCA_RuntimeException but I don't think it's heavily relied upon in our current bindings). > Bindings give us some flexibility to control levels of detail but I > think in the majority of cases the level of detail will be low (in > terms of stack traces). Not sure we should look to binding.sca as a > control point on this as in the full SCA world binding.sca can work > remotely too. It's possible that the default php binding would provide > more info but not sure it's worth the effort of making an exceptional > case. > I was actually meaning for binding.sca to be a remote binding. The remote equivalent to binding.php. In other words, if you want to define a 'module' boundary where the full exception information flows, then you use binding.php for local and binding.sca for remote (probably using soap as it's implementation). If you want to define a business service interface then you use the other bindings (soap, json- rpc, and so on). Does that make sense? > My 2c > > Simon --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "phpsoa" group. To post to this group, send email to phpsoa@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en -~----------~----~----~----~------~----~------~--~---
