Coding with errors in mind - a solution?

[michaelslists at gmail.com (mikeiscool)]

On 9/1/06, Pascal Meunier <pmeunier at cerias.net> wrote:
> 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?

His point, I think, is that if you wrap a series of statements in an
try/catch block, you might not roll back every statement you needed
to, or checked appropriate conditions.

For example:
try {
 openFile();
 getData();
 writeToFile();
 setSomeFlag()
 moveFile();
 deleteTempThings();
} catch(Exception e){
 ...
}

Now obviously that's a statement that could be written far better, but
the point is that with the lazy/bad/accidental-bug-producing
programmer it might be common.


> > (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.

Exceptions simplify the code? I don't think so. They also don't reduce
code duplication [per se] you need to add extra functions, etc, to do
that.


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

They _can_ be, but often aren't.


> Pascal Meunier

-- mic