How much data should flow back from a business exception?

Discussion:

Matthew Peters

2007-05-15 17:08:17 UTC

Mike Caplan (in pecl bug #10994) has raised the question of whether,
when a business exception is raised in a component that has been
called remotely - through a web service, say - the exception should be
serialised and flowed back, then deserialised and rethrown in its
entirety on the calling end. At the moment the exception is recreated
in loving detail, with the same backtrace, line number, file name,
that it had on the remote end. This makes the exception identical
regardless of whether the components are local or remote. Mike
suggests that that is too much information and it would be better to
keep just the text and number. I can see his point. Perhaps it was a
step too far to flow back the backtrace. One possibility is to put the
behaviour under control of a config setting somewhere.

What do other people think?

Matthew

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

Graham Charters

2007-05-16 10:05:52 UTC

Permalink

I think Mike is right that we shouldn't always flow this information.
It is a potential security hole as it could divulge more information
than we would like. I had similar concerns about the information we
flow back in http responses for things like Atompub and the conclusion
was to not give any implementation details away.

I think we have two scenarios here, which are potentially conflicting.

1. I want to expose a service to a thirdparty and only want to flow
back information relation to the integration of our businesses
(business exceptions without any implementation detail).
2. I want to be able to define 'module' boundaries which can be
running on the same server or potentially remote. I want the same
semantics and details to flow across the interfaces, including
exception details when remote using Web services (this is within my
organisation).

I can think of a couple ways to resolve this:

1. We give the developer more control over what flows (either through
a config setting or through the exceptions they throw (perhaps one
class of exception (e.g business) does not flow backtrace, and another
class (e.g. system) does. It's then up to the developer to define
which services are business boundaries and which are module
boundaries.
2. We create another binding (there is this concept of binding.sca in
the specifications), whos purpose is to be used for scenario 2. This
binding would flow the backtrace, and we would remove the backtrace
for binding.soap.

Graham.

Post by Matthew Peters
Mike Caplan (in pecl bug #10994) has raised the question of whether,
when a business exception is raised in a component that has been
called remotely - through a web service, say - the exception should be
serialised and flowed back, then deserialised and rethrown in its
entirety on the calling end. At the moment the exception is recreated
in loving detail, with the same backtrace, line number, file name,
that it had on the remote end. This makes the exception identical
regardless of whether the components are local or remote. Mike
suggests that that is too much information and it would be better to
keep just the text and number. I can see his point. Perhaps it was a
step too far to flow back the backtrace. One possibility is to put the
behaviour under control of a config setting somewhere.
What do other people think?
Matthew

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

simonslaws-gM/Ye1E23mwN+

2007-05-18 11:29:13 UTC

Permalink

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.

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.

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-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

Graham Charters

2007-05-18 16:08:28 UTC

Permalink

Hi Simon, thanks for your 2c - it's always worth more than that :-)

I've inlined some questions/responses below.

Post by Graham Charters
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).

Post by Graham Charters
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?

Post by Graham Charters
My 2c
Simon

Caroline Maynard

2007-05-20 21:22:56 UTC

Permalink

Post by Matthew Peters
What do other people think?

Matthew, the way I handled this in SDO was to introduce a "cause"
property, with a getCause() public accessor, plus an additional
optional parameter on the constructor for setting it. You can assign
any object into the cause, though normally it would be the originating
exception.

Keeping this data separate from the other properties of the exception
gives you a choice over when it is output. In particular, there's no
reason for the getMessage() output to be the same as the __toString()
output. Whereas if you have logging turned on, I'd expect all available
data, including the cause, to be written to the log.

Using these two techniques may give you enough control to preserve the
information for when it's needed without displaying it when it's
inappropriate.

(BTW, I didn't myself make up this pattern, I just copied it from
Another Language Beginning with J.)

--
Caroline

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

Matthew Peters

2007-05-23 15:34:44 UTC

Permalink

OK, several things got discussed here but picking out the essential
attitude to the initial question:

Mike C says (I am quoting from pecl defect 10994):
" I would like to suppress everything with the exception of the
exception description and number. Exposing files and backtraces in
exceptions to the end user I think is too much info to expose (for
security reasons, and simplicity). "

Graham says
"I think Mike is right that we shouldn't always flow this information.
It is a potential security hole as it could divulge more information
than we would like."

Simon says
"I wouldn't expect that a stack trace is required or
even useful."

That seems a pretty clear message that the default behaviour at least
should be to suppress the details from the remote exception. We can
debate another time on whether or how it should be revealed, if anyone
ever wants it.

So, any volunteers to chop it out? We could stop generating the "This
wsdl was generated..." comment at the bottom of the wsdl since it was
only used for that.

Matthew

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "phpsoa" group.
To post to this group, send email to phpsoa-/***@public.gmane.org
To unsubscribe from this group, send email to phpsoa-unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

Graham Charters

2007-06-04 10:44:24 UTC

Permalink

Post by Matthew Peters
So, any volunteers to chop it out? We could stop generating the "This
wsdl was generated..." comment at the bottom of the wsdl since it was
only used for that.

Isn't this used to identify and unwrap the interface of the doc/lit
wrapped service? If this is the case, then we still can't remove it.

Post by Matthew Peters
Matthew

Matthew Peters

2007-06-07 15:14:43 UTC

Permalink

You're right of course, we still need the comment, for the reason you
mention. All the rest still stands.

Post by Graham Charters
Isn't this used to identify and unwrap the interface of the doc/lit
wrapped service? If this is the case, then we still can't remove it.