Re: [snapdal-devel] Sql and parameters in the exception message

[Scott H. <sk...@eo...>]

It seems like exceptions from snapdal should be as comprehensive as
possible. Isn't one solution to just have snapdal relate exceptions by
nesting the original exception. Snapdal doesn't need to replace the
underlying exception, and strip the real information, it can just wrap it.

Also, since no end user will directly interact with the snapdal library (the
library will be used by other applications) it is the developers (of the end
user application) responsibility to keep sensitive information from the end
user.

----- Original Message ----- 
From: "Philip Nelson" <pan...@ya...>
> I got an extensive update to the vb version of SnapDAL from Barry Sirote.
Most
> of the updates are nice simple things that make sense to incorporate into
the
> c# version. What constitues the greatest change though is much more
detailed
> exception messages.
>
> There is no question that detailed messages aid in troubleshooting
problems. My
> only reservation is that some naive implementations will show the full
text of
> an exception to end users, and this could expose application details that
> shouldn't be exposed. You may expose a user's clear text password to a
system
> operator, or credit card numbers could get logged to a text file that
support
> personnel might have access to.
>
> On the other hand, these very details could make helping a problem one of
these
> end users has much easier to solve. You could also argue that any message
> included in an exception exposes to much program detail, so what's the
> difference.  As long as you don't include system passwords, you would
probably
> be better off.
>
> I'm torn, what do you all think?  I'm all for helping debug problems, and
all
> for hiding details as much as possible from the outside. Perhaps
properties of
> the exception that expose these things, but not the Message?