CODEWITHSUNDEEP
functioncoding-stylemethodsreturn-value
Drew
Drew

Reputation: 6274

Should all methods that do something but don't return data return a success code?

A simple best practices question that I haven't seen addressed in the introductory programming books I've read...

If a function or method does an action but does not return real data, an example being a function that increments a class property or a database value, should it always return a boolean success value?

Part of me says "of course, duh", and then part of me says my code would quickly overflow with boolean success checks on every little operation.

Currently I check success on critical functions, but not on cascading functions that run if the critical check is passed, on the assumption that the success of the first ensures valid data/success of the following ones.

But I'm just a hobbyist. What do the pros do?

Upvotes: 2

Views: 1334

Answers (4)

Don Roby
Don Roby

Reputation: 41137

Opinions will vary on this, as on many questions of "best practice".

But there is a commonly held principle called Command-query separation that says that a method should either do something or return a value and not both.

Rather than return a boolean success/failure from everything, I prefer to use exceptions for the failures, and not return anything from methods whose purpose is to do something.

Upvotes: 0

Indy-Jones
Indy-Jones

Reputation: 728

Honestly there's the right way to do things and there's the I need to get this done way to do things. Many times I find myself in both situations.

The difference I feel is that I'm rather good at looking at an application and seeing where the potential for weak links are. Those are the ones that I have error checks and boolean values returned. I think its a bit overkill with returning booleans on all functions that don't return a value, however in those situations a simple try catch is a very nice way to see if a function is not working properly and safely exiting or redirecting vs. crashing the app.

I'm sure there's some hard coders who truly believe in classing and returning booleans for everything, and they are in fact correct...however sometimes you are dealing with items you cannot control, such as a client's server configuration, an existing app's coding platform, etc.

Just my 20+ years of dealing with difficult situations and getting called by clients who need an app created or fixed in a week or less.

Upvotes: 0

Ry-
Ry-

Reputation: 225074

Returning success values when you don't expect something to fail is generally bad design. You can forget to check the return values or check them in the wrong way, and if you start to use different values for different errors, things quickly get out of hand. (-1: success or failiure? It depends on the writer!)

Instead, you should use exceptions for exceptional circumstances. When exceptions are unhandled, they usually cause the termination of the application, which certainly makes you remember to check them. Their syntax is clear and you don't litter your code with checks.

You haven't specified a language, so here's a VB.NET example that divides a number:

Function FloorDivide(ByVal a As Integer, ByVal b As Integer) As Integer
    Dim result As Boolean = a / b

    If Double.IsNaN(result) Then Throw New DivideByZeroException()

    Return CInt(Math.Floor(result))
End Function

You can use it without checking the success value, but you can still handle errors using Try...Catch statements:

Try
    FloorDivide(1, 0)
Catch ex As DivideByZeroException
    MessageBox.Show("Something went terribly wrong! :D")
    'Exit, maybe?
End Try

(Not that I'm saying you should guard against divide-by-zero in this way; filter your input!)

If you do forget to make that check, you'll soon be reminded in the testing phase instead of having your code silently fail. It's also much cleaner, and the scope of a Try...Catch can be as large as you want, perhaps handling any error occurring in a particular error-prone method and throwing them away. Who knows?

So, generally, use exceptions. If you find yourself planning to handle them, though, you need to do validation.

Upvotes: 0

cmsjr
cmsjr

Reputation: 59215

It really depends on the language and paradigm you are following. I would have a tendency to have methods that do not return a value throw an exception if they fail and handle the exception, and return nothing (in the void sense) if they succeed. This is strongly influenced by the fact that most of, if not all, the languages I work with support exception handling. In a language that did not support exception handling I would probably return a numeric value with a defined value for success and then have the latitude to return a variety of values for different kinds of failure, but only in cases where failure was clearly possible.

So to answer your question...probably not. Doing it for all methods would be too much overhead in the first place, and for the places it needs to be done boolean success/fail is probably not the best answer.

Upvotes: 1

Related Questions