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

[Chad M. G. <cg...@ne...>]

I would recommend keeping any important info out of the Message property.
And certainly, you would always want to include the actual exception as the
inner.  Any important info, such as CC# in the current statment's
parameters, can be exposed through a collection off of the new typed
exception.  As you mentioned, it would then be the developers choice to log
the exception as they choose either "dumping" the parameters or not.  Some
things I can think of that may be a good idea with the DAL exceptions would
be obviously have some SnapDALDataException base class that has props like
StatementName and Parameters.  Then having exceptions like
SnapDALUniqueViolationException (caused by constraint or unique index and
try to extract the constraint/index name), SnapDALDeadlockException,
SnapDALTimeoutException, SnapDALConfigFileNotFound, and any other common
data provider errors or meaningful "throw new Exception()" calls that are in
SnapDal that should be a typed exception.

Chad

----- Original Message ----- 
From: "Scott Hernandez" <sk...@eo...>
To: "snapdal" <sna...@li...>
Sent: Tuesday, April 27, 2004 4:07 PM
Subject: Re: [snapdal-devel] Sql and parameters in the exception message


>
> 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?
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Snapdal-devel mailing list
> Sna...@li...
> https://lists.sourceforge.net/lists/listinfo/snapdal-devel