Coding with errors in mind - a solution?

[pmeunier at cerias.net (Pascal Meunier)]

On 8/30/06 3:46 PM, "Tim Hollebeek" <tholleb at teknowledge.com> wrote:

> What you've proposed are exceptions.  They do help (some) in separating
> the normal logic from error handling, but:
>
> (1) they often leave the job "half done" which has its own risks.
>     writing exception safe code can be more of a nightmare than error
> checking.

I can't help noticing...  In Ruby there's an "ensure" clause that allows you
to bring closure to half-done operations.  Perhaps your point is that some
languages have poor exception support, just like some languages don't
provide safe string handling functions?

> (2) in many languages, you can't retry or resume the faulting code.
>     Exceptions are really far less useful in this case.

See above.  (Yes, Ruby supports retrying).

> (3) you usually end up with some "generic" clean up code, which generally
>     hides more errors than it solves.

I don't think that's fair.  Yes, you can write poor exception handling code,
but it's far easier to simply ignore or overlook errors or write poor error
handling code to the point where the error is effectively ignored (or
"hidden") or the cause of the error becomes unidentifiable.  Exceptions
allow me to reduce code duplication (and lower the chance of inconsistent
treatment and bugs), simplify the code (which makes it easier to understand
and therefore audit) as well as handle problems at an appropriate layer in
the code. 

I'm not saying that exceptions are always the best way to handle things, but
they can be part of good programming practices.

Pascal Meunier

> Tim Hollebeek
> Research Scientist
> Teknowledge, Corp.
>
> > -----Original Message-----
> > From: sc-l-bounces at securecoding.org
> > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Michael S Hines
> > Sent: Wednesday, August 30, 2006 11:07 AM
> > To: sc-l at securecoding.org
> > Subject: [SC-L] Coding with errors in mind - a solution?
> >
> > a simple structure that provides for errors would go a long way...
> >  
> > If - then - else - on error
> > Do - end - on error
> > Let x = y - on error
> > Let x = function() on error
> > etc...    
> >  
> > The problem is writing code without thinking of the possible
> > errors that might arise.   This forces you to think about the
> > consequences of executing a command...
> >  
> > Where 'error' is doing something intelligent when the
> > original command doesn't work...
> >  
> > Just a brainstorm....... any merit to it?
> >  
> > Mike Hines
> > mshines at purdue.edu
> >
> > ________________________________
> >
> > From: sc-l-bounces at securecoding.org
> > [mailto:sc-l-bounces at securecoding.org] On Behalf Of Ed Reed (Aesec)
> > Sent: Wednesday, August 30, 2006 1:17 PM
> > To: sc-l at securecoding.org
> > Subject: [SC-L] e: How can we stop the spreading insecure
> > coding examples at, training classes, etc.?
> >
> >
> >
> > Message: 1
> > Date: Tue, 29 Aug 2006 15:48:17 -0400
> > From: pmeunier at purdue.edu
> > Subject: Re: [SC-L] How can we stop the spreading
> > insecure coding
> > examples at training classes, etc.?
> > To: "Wall, Kevin" <Kevin.Wall at qwest.com>
> > <mailto:Kevin.Wall at qwest.com>
> > Cc: SC-L at securecoding.org
> > Message-ID: 
> > <1156880897.44f49a01620aa at webmail.purdue.edu>
> > <mailto:1156880897.44f49a01620aa at webmail.purdue.edu>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Quoting "Wall, Kevin" <Kevin.Wall at qwest.com>
> > <mailto:Kevin.Wall at qwest.com> :
> >
> >
> >  
> >
> > I think that this practice of leaving out the "security
> > details" to just make the demo code short and
> > sweet has got
> > to stop. Or minimally, we have to make the code
> > that people
> > copy-and-paste from have all the proper
> > security checks even
> > if we don't cover them in training. If we're
> > lucky, maybe
> > they won't delete them when the re-use the code.
> >    
> >
> >
> > I agree, and would like to extend it: security should
> > be discussed *at the same
> > time* that a topic is.  Teaching security in a separate
> > class, like I have been
> > doing, reaches only a fraction of the audience, and
> > reinforces an attitude of
> > security as an afterthought, or security as an option.
> > Comments in the code
> > should explain (or refer to explanations of) why
> > changing or deleting those
> > lines is a bad idea.
> >
> > However, I'm afraid that it would irritate students,
> > and make security the new
> > "grammar and spelling" for which points are deducted
> > from "perfectly valid
> > write-ups" (i.e., "it's my ideas that count, not how
> > well I spell"). 
> >
> > The same used to be said about unstructured programming
> > examples (computed gotos, spaghetti code, multiple entry and
> > exit points from functions, etc).  We got past it.
> >
> > We need a similar revolution in thought with regard to
> > security, and some one to take the lead on providing clear,
> > crisp examples of coding style that is more secure by its
> > nature.  I don't have one handy - but that's my wish.
> >
> > Ed
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php