Pre / post conditions in error handling

Hello all,

I found Herb Sutter's article regarding error handling in the most recent
CUJ to be very, very good. However, in trying to apply what I learned from
the article, I am left with some questions.

I have a function that takes a std::string (that represents a file name) as
a parameter. This function reads in the contents of the file and returns a
struct representing the file's content.

Two things could go wrong inside the function:

1. The function might find that the file does not exist
2. The function might find that the content of the file is invalid

(Some might consider 1 to be a special case of 2.)

The question is: Are these cases a violation of the function's preconditions
or postconditions? According to the error handling philosophy advocated by
Herb in his article, if it is a precondition violation, it should have been
reported as an error in the calling function. Since it wasn't, we should
report a program bug via an assert in the called function. If it is a
postcondition violation, it should be reported as an error in the called
function. Since whether the problem is a precondition or postcondition
problem determines where the error gets reported, it is something I need to
know to properly write my code.

I can reason that these are precondition violations since it seems
justifiable to say that a precondition for the function is that the file
both exist and have valid content.

However, I can also make a reasonable argument that it is a postcondition
violation since the function cannot construct a valid return value. In this
case, the precondition would be nothing more than that the string object
passed in be valid. If it's a valid std::string, the precondition is met,
period.

So, I need a little more guidance than that provided in the article as to
how to classify a problem as a precondition or postcondition violation. I'm
thinking that perhaps it is a subjective thing and that either way you go
could be OK as long as you're consistent. All help will be appreciated!

Thanks,
Dave

re: Pre / post conditions in error handling

* Dave:[color=blue]
>
> I found Herb Sutter's article regarding error handling in the most recent
> CUJ to be very, very good.[/color]

Haven't read that. Link?

[color=blue]
> However, in trying to apply what I learned from
> the article, I am left with some questions.
>
> I have a function that takes a std::string (that represents a file name) as
> a parameter. This function reads in the contents of the file and returns a
> struct representing the file's content.
>
> Two things could go wrong inside the function:
>
> 1. The function might find that the file does not exist
> 2. The function might find that the content of the file is invalid
>
> (Some might consider 1 to be a special case of 2.)
>
> The question is: Are these cases a violation of the function's preconditions
> or postconditions? According to the error handling philosophy advocated by
> Herb in his article, if it is a precondition violation, it should have been
> reported as an error in the calling function. Since it wasn't, we should
> report a program bug via an assert in the called function. If it is a
> postcondition violation, it should be reported as an error in the called
> function. Since whether the problem is a precondition or postcondition
> problem determines where the error gets reported, it is something I need to
> know to properly write my code.
>
> I can reason that these are precondition violations since it seems
> justifiable to say that a precondition for the function is that the file
> both exist and have valid content.
>
> However, I can also make a reasonable argument that it is a postcondition
> violation since the function cannot construct a valid return value.
>
> In this
> case, the precondition would be nothing more than that the string object
> passed in be valid. If it's a valid std::string, the precondition is met,
> period.
>
> So, I need a little more guidance than that provided in the article as to
> how to classify a problem as a precondition or postcondition violation. I'm
> thinking that perhaps it is a subjective thing and that either way you go
> could be OK as long as you're consistent. All help will be appreciated![/color]

It's very easy: don't have condition X as a precondition unless the
caller _can_ ensure that condition X holds (and in that case, if you
choose to have X as precondition then a violation is a logic error).

When you don't have condition X as precondition, but X is needed to
return a useful result: if X can be checked for, then it is a design
issue -- what's most practical -- whether the function should
guarantee the useful result on successful execution, or whether it
should also have X-didn't-hold as a possible normal case result.

A guaranteed useful result means X violation should throw exception.

Otherwise, one way of reporting a possibly "null" result is by using a
wrapper object that either is empty or logically contains the useful
result. The case where the useful result is a simple or small value
type has its own little pattern name, which I forget...

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

re: Pre / post conditions in error handling

"Alf P. Steinbach" <alfps@start.no> wrote in message
news:40fe0c4c.543359343@news.individual.net...[color=blue]
> * Dave:[color=green]
> >
> > I found Herb Sutter's article regarding error handling in the most[/color][/color]
recent[color=blue][color=green]
> > CUJ to be very, very good.[/color]
>
> Haven't read that. Link?
>
>[color=green]
> > However, in trying to apply what I learned from
> > the article, I am left with some questions.
> >
> > I have a function that takes a std::string (that represents a file name)[/color][/color]
as[color=blue][color=green]
> > a parameter. This function reads in the contents of the file and[/color][/color]
returns a[color=blue][color=green]
> > struct representing the file's content.
> >
> > Two things could go wrong inside the function:
> >
> > 1. The function might find that the file does not exist
> > 2. The function might find that the content of the file is invalid
> >
> > (Some might consider 1 to be a special case of 2.)
> >
> > The question is: Are these cases a violation of the function's[/color][/color]
preconditions[color=blue][color=green]
> > or postconditions? According to the error handling philosophy advocated[/color][/color]
by[color=blue][color=green]
> > Herb in his article, if it is a precondition violation, it should have[/color][/color]
been[color=blue][color=green]
> > reported as an error in the calling function. Since it wasn't, we[/color][/color]
should[color=blue][color=green]
> > report a program bug via an assert in the called function. If it is a
> > postcondition violation, it should be reported as an error in the called
> > function. Since whether the problem is a precondition or postcondition
> > problem determines where the error gets reported, it is something I need[/color][/color]
to[color=blue][color=green]
> > know to properly write my code.
> >
> > I can reason that these are precondition violations since it seems
> > justifiable to say that a precondition for the function is that the file
> > both exist and have valid content.
> >
> > However, I can also make a reasonable argument that it is a[/color][/color]
postcondition[color=blue][color=green]
> > violation since the function cannot construct a valid return value.
> >
> > In this
> > case, the precondition would be nothing more than that the string object
> > passed in be valid. If it's a valid std::string, the precondition is[/color][/color]
met,[color=blue][color=green]
> > period.
> >
> > So, I need a little more guidance than that provided in the article as[/color][/color]
to[color=blue][color=green]
> > how to classify a problem as a precondition or postcondition violation.[/color][/color]
I'm[color=blue][color=green]
> > thinking that perhaps it is a subjective thing and that either way you[/color][/color]
go[color=blue][color=green]
> > could be OK as long as you're consistent. All help will be appreciated![/color]
>
> It's very easy: don't have condition X as a precondition unless the
> caller _can_ ensure that condition X holds (and in that case, if you
> choose to have X as precondition then a violation is a logic error).
>
> When you don't have condition X as precondition, but X is needed to
> return a useful result: if X can be checked for, then it is a design
> issue -- what's most practical -- whether the function should
> guarantee the useful result on successful execution, or whether it
> should also have X-didn't-hold as a possible normal case result.
>
> A guaranteed useful result means X violation should throw exception.
>
> Otherwise, one way of reporting a possibly "null" result is by using a
> wrapper object that either is empty or logically contains the useful
> result. The case where the useful result is a simple or small value
> type has its own little pattern name, which I forget...
>
> --
> A: Because it messes up the order in which people normally read text.
> Q: Why is it such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?[/color]

As far as a link goes, there isn't one available at this time as the article
is in print. If anyone else knows of a link I didn't find, please post...
Thanks!

re: Pre / post conditions in error handling

"Dave" <better_cs_now@yahoo.com> wrote in message
[color=blue]
> Two things could go wrong inside the function:
>
> 1. The function might find that the file does not exist
> 2. The function might find that the content of the file is invalid
>
> (Some might consider 1 to be a special case of 2.)
>
> The question is: Are these cases a violation of the function's[/color]
preconditions[color=blue]
> or postconditions? According to the error handling philosophy advocated[/color]
by[color=blue]
> Herb in his article, if it is a precondition violation, it should have[/color]
been[color=blue]
> reported as an error in the calling function. Since it wasn't, we should
> report a program bug via an assert in the called function. If it is a
> postcondition violation, it should be reported as an error in the called
> function. Since whether the problem is a precondition or postcondition
> problem determines where the error gets reported, it is something I need[/color]
to[color=blue]
> know to properly write my code.[/color]

Precondition and postconditions should test constraints between the member
variables of the class, as far as I know. For the two things that could go
wrong, I don't see a straightforward way to fit them into this scheme. So
my design decision is to throw an exception.
These seem to be