The Right Approach to Exceptions

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Feb 24 08:27:44 PST 2012


On Fri, Feb 24, 2012 at 07:57:13AM -0800, H. S. Teoh wrote:
> > On Thursday, February 23, 2012 15:18:27 H. S. Teoh wrote:
> > > In my book, a linked library shares equal status with the "main
> > > program", therefore the definition of "user input" still sits at
> > > the internal-to-program and external boundary.
[...]
> I wasn't trying to say that library code should always use DbC and
> application code should always use defensive programming. I'm saying
> that if it makes sense for a function to use DbC (or vice versa) then
> it should use DbC regardless of whether it's in a library or not.
[...]

Argh, I just realized that my first post was so poorly worded it made no
sense at all. My second post was what I meant to say. :)

What I was trying to express in the first post was that "user input"
comes from a source external to the program, whether from a user typing
at the keyboard, or from a file or network resource, and this data
traverses program code paths until eventually they are converted into
the internal form the program uses for further processing.  Input
sanitization should be done along this code path until the input is
processed into program-internal form, at which point, DbC begins to take
effect, the assumption being that after preprocessing by the input
sanitization code, all data should be valid, and if not, it's a failure
of the input processing code and represents a logic flaw in the program,
therefore an assertion should be thrown.


T

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.


More information about the Digitalmars-d mailing list