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, simonsl... googlemail.com 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
phpsoa-unsubscribe googlegroups.com
For more options, visit this group at http://
groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---
|