Thread: Return void or success/fail?

What would be the proper return type for few samples of functions below? "void" for nothing or "int" to indicate succes/fail operation?

Code:

returnType makeEmpty()
returnType insert( ItemType newItem )

...and other similar functions

*All* books that I've read would have "void" as a return type, but the....
some people suggests to return operation success state. I believe that's the return type for functions in library, e.g

Code:

while ( getline( ... ) ) { ... }

So...?

well if you want them to return a value upon success or failure i would go for a bool type. I hope this is what you meant

It could be "bool" instead of "int"
Basically the question is to return VOID or OPERATION_STATE

Can someone point me to a book that will suggest to return OPERATION_STATE, 'cause like I said I haven't encountered one?

Originally Posted by alphaoide

It could be "bool" instead of "int"
Basically the question is to return VOID or OPERATION_STATE

Can someone point me to a book that will suggest to return OPERATION_STATE, 'cause like I said I haven't encountered one?

The operation state would be true if the function completed its task successfuly and false otherwise

Code:

bool someFunction(int arg)
{
     return true;  // operation state is true indicating successful operation
}

or you could have a more verbose operation state by returning an int with differing values representing the outcomes of your function return 0 being success

>>>Can someone point me to a book that will suggest to return OPERATION_STATE, 'cause like I said I haven't encountered one?
>The operation state would be true if the function completed its task successfuly and false otherwise



I can't say I've encountered a book that would suggest a return value (or none I can think of), but then those are mostly beginner books that are just trying to demonstrate how the function would accomplish the said task (i.e. show how to insert). But any book that details error handling extensively would probably do so.

Why are you looking for a book anyway? Are you actually going to buy one for the sake of it suggesting you to do something that you would already have done anyway, or is this just to prove a point, or are you thinking that a book that would make the suggestion would be a cut above the rest?

I tend to almost always return status values, but the problem is I'm always to lazy to check them when I call the functions

Finally I found one book that gives detailed explanation on this issue. For those who cares...
McConnell, Steve. Code Complete. 2nd Ed. 2004: Microsoft Press.

When to Use a Function and When to Use a Procedure
Purist argue that a function should return only one value, just as a mathematical function does. This means that a function would take only input parameters and return its only value through the function itself. The function would always be named fo the value it returned, as sin(), CustomerID(), and ScreenHeight() are. A procedure, on the other hand could take input, modify, and output parameters-as many of each as it wanted to.

A common programming practice is to have a function that operates as a procedure and returns a status value. Logically, it works as a procedure, but because it returns a value, it's officially a function. For example, you might have a routine called FormatOutput() used with a report object in statements like this one:

Code:

if ( report.FormatOutput( formattedReport ) = Succes ) then ...

In this example, report.formatOutput() operates as a procedure in that it has an output parameter, formattedReport, but it is technically a function because the routine itself returns a value. Is this a valid way to use a function? In defense of this approach, you could maintain that the function return value has nothing to do with the main purpose of the routine, formatting output, or with the routine name, report.FormatOutput(). In that sense it operates more as a procedure does even if it is technically a function. The use of the return value to indicate the success or failure of the procedure is not confusing if the technique is used consistenly.

The alternative is to create a procedure that has a status variable as an explicit paramater, which promotes code like this fragment:

Code:

report.FormatOutput( formattedReport, outputStatus )
if ( outputStatus = Success ) then ...

I prefer the second style style of coding, not because I'm hard-nosed about the difference between functions and procedures but because it makes a clear separation etween the routine call and the test of the status value. To combine the call and the test into one line of code increases the density of the statement and, correspondingly, its complexity. The following use of a function is fine too:

Code:

outputStatus = report.FormatOutput( formattedReport )
if ( outputStatus = Success ) then ...

In short, use a function if the primary purpose of the routine is to return the value indicated by the function name. Otherwise, use a procedure.

I did read something about whether or not to use exceptions to handle common errors. If I remeber correctly, the bottom line was no, although it could also have been depends. But the argument goes, exceptions should only be used when something truly exceptional happens. Actually, I don't think I've ever used exceptions yet.

Originally Posted by Hunter2

I did read something about whether or not to use exceptions to handle common errors. If I remeber correctly, the bottom line was no, although it could also have been depends. But the argument goes, exceptions should only be used when something truly exceptional happens. Actually, I don't think I've ever used exceptions yet.

Actually, I'm reading it right now

Throw an exception only for conditions that are truly exceptional
Exceptions should be reserved for conditions that are truly exceptional-in other words, for conditions that cannot be addressed by other conding paractices. Exceptions are used in similar circumstances to assertions-for events that are not just infrequent but for events that should never occur.
McConnell, Steve. Code Complete. 2nd Ed. 2004: Microsoft Press.

Odd, actually I think I read it in Sam's Teach Yourself C(or ++) in 21 Days I guess it's just a popular maxim.

dang, jlou, your two cents is worth a million to me.