General Question On Handling of Function results.

[Mr Newbie]

I am often in the situation where I want to act on the result of a function,
but a simple boolean is not enough. For example, I may have a function
called

isAuthorised ( User, Action ) as ?????

OK, this function may return a boolean, and if this is true, then no message
back is really required, but if it fails then some supporting message needs
to be returned to the calling code. As I see it there are a few options.

1.) Throw an exception with the message in ( But this tends to slow down
execution a little ?? )

2.) Return an enumeration type, but this is a little cumbersome because it
means I have to define all my possible return combinations against a number,
which could become messy.

3.) Add a third parameter called message which can be set to any error
message returned.

4.) Return a structure which contains a boolean and a string describing the
result.


Can I ask what you guys normally do in this situation, what is best
practice, pros and cons etc.


Thanks

Mr N

 

[m.posseth]

I normally use option 4 , i create a structure with the required info and
return this if i need to return multiple values

use exception handling if you do not see anny other way, it is much faster
if you can evaluate a value and return this to take apropriate action as to
use a try catch statement or throwing errorr

regards

Michel Posseth [MCP]

 

[Mr Newbie]

Thanks for your reply. Option 4 is of course the purist way to do this and
sits nicley with what we think about functions, put things in the arguments
return something back. Just out of curiosity, do you have an objection to
option 3, and if so what would it be ?

--
Best Regards

The Inimitable Mr Newbie º¿º

I normally use option 4 , i create a structure with the required info and
return this if i need to return multiple values

use exception handling if you do not see anny other way, it is much
faster if you can evaluate a value and return this to take apropriate
action as to use a try catch statement or throwing errorr

regards

Michel Posseth [MCP]

I am often in the situation where I want to act on the result of a
function, but a simple boolean is not enough. For example, I may have a
function called

isAuthorised ( User, Action ) as ?????

OK, this function may return a boolean, and if this is true, then no
message back is really required, but if it fails then some supporting
message needs to be returned to the calling code. As I see it there are a
few options.

1.) Throw an exception with the message in ( But this tends to slow down
execution a little ?? )

2.) Return an enumeration type, but this is a little cumbersome because
it means I have to define all my possible return combinations against a
number, which could become messy.

3.) Add a third parameter called message which can be set to any error
message returned.

4.) Return a structure which contains a boolean and a string describing
the result.


Can I ask what you guys normally do in this situation, what is best
practice, pros and cons etc.


Thanks

Mr N

 

[Oenone]

Can I ask what you guys normally do in this situation, what is best
practice, pros and cons etc.

I've personally used both of the following approaches to solving the
problem:

1. Pass in a ByRef String, through which any messages can be returned from
the function.

2. Get the function to return a String, and use the presence of something in
the string to indicate whether the function succeeded or not. So if an empty
string is returned, the authorised check succeeded; if a message was
returned then the check failed.

Either way, it's well worth providing a good level of commenting (both in
the function itself and the code that calls it) to describe the non-obvious
behaviour of your function.

 

[m.posseth]

personally i do not have anything against option 3 however i feel option 4
is more straightforward in what is happening ( the code explains itself )
while using a byref value to create an extra return value
might confuse another programmer working new on the project , and as we are
now all working with objects why not a return object ?

regards

Michel Posseth [MCP]

Thanks for your reply. Option 4 is of course the purist way to do this
and sits nicley with what we think about functions, put things in the
arguments return something back. Just out of curiosity, do you have an
objection to option 3, and if so what would it be ?

--
Best Regards

The Inimitable Mr Newbie º¿º

I normally use option 4 , i create a structure with the required info and
return this if i need to return multiple values

use exception handling if you do not see anny other way, it is much
faster if you can evaluate a value and return this to take apropriate
action as to use a try catch statement or throwing errorr

regards

Michel Posseth [MCP]

I am often in the situation where I want to act on the result of a
function, but a simple boolean is not enough. For example, I may have a
function called

isAuthorised ( User, Action ) as ?????

OK, this function may return a boolean, and if this is true, then no
message back is really required, but if it fails then some supporting
message needs to be returned to the calling code. As I see it there are
a few options.

1.) Throw an exception with the message in ( But this tends to slow
down execution a little ?? )

2.) Return an enumeration type, but this is a little cumbersome because
it means I have to define all my possible return combinations against a
number, which could become messy.

3.) Add a third parameter called message which can be set to any error
message returned.

4.) Return a structure which contains a boolean and a string describing
the result.


Can I ask what you guys normally do in this situation, what is best
practice, pros and cons etc.


Thanks

Mr N

 

[Mr Newbie]

Excellent answer, you have made a very good argument for option 4 as being
the best choice.

I will addopt this principle from now onwards.

This brings me to a related but slightly different question. When is it
most appropriate to throw an exception rather than handling the error in a
structured way by testing results.





--
Best Regards

The Inimitable Mr Newbie º¿º

personally i do not have anything against option 3 however i feel option
4 is more straightforward in what is happening ( the code explains
itself ) while using a byref value to create an extra return value
might confuse another programmer working new on the project , and as we
are now all working with objects why not a return object ?

regards

Michel Posseth [MCP]

Thanks for your reply. Option 4 is of course the purist way to do this
and sits nicley with what we think about functions, put things in the
arguments return something back. Just out of curiosity, do you have an
objection to option 3, and if so what would it be ?

--
Best Regards

The Inimitable Mr Newbie º¿º

I normally use option 4 , i create a structure with the required info and
return this if i need to return multiple values

use exception handling if you do not see anny other way, it is much
faster if you can evaluate a value and return this to take apropriate
action as to use a try catch statement or throwing errorr

regards

Michel Posseth [MCP]

I am often in the situation where I want to act on the result of a
function, but a simple boolean is not enough. For example, I may have a
function called

isAuthorised ( User, Action ) as ?????

OK, this function may return a boolean, and if this is true, then no
message back is really required, but if it fails then some supporting
message needs to be returned to the calling code. As I see it there are
a few options.

1.) Throw an exception with the message in ( But this tends to slow
down execution a little ?? )

2.) Return an enumeration type, but this is a little cumbersome because
it means I have to define all my possible return combinations against a
number, which could become messy.

3.) Add a third parameter called message which can be set to any error
message returned.

4.) Return a structure which contains a boolean and a string describing
the result.


Can I ask what you guys normally do in this situation, what is best
practice, pros and cons etc.


Thanks

Mr N

 

[Mr Newbie]

PS : I have started a new thread on this subject

--
Best Regards

The Inimitable Mr Newbie º¿º

Excellent answer, you have made a very good argument for option 4 as being
the best choice.

I will addopt this principle from now onwards.

This brings me to a related but slightly different question. When is it
most appropriate to throw an exception rather than handling the error in a
structured way by testing results.





--
Best Regards

The Inimitable Mr Newbie º¿º

personally i do not have anything against option 3 however i feel option
4 is more straightforward in what is happening ( the code explains
itself ) while using a byref value to create an extra return value
might confuse another programmer working new on the project , and as we
are now all working with objects why not a return object ?

regards

Michel Posseth [MCP]

Thanks for your reply. Option 4 is of course the purist way to do this
and sits nicley with what we think about functions, put things in the
arguments return something back. Just out of curiosity, do you have an
objection to option 3, and if so what would it be ?

--
Best Regards

The Inimitable Mr Newbie º¿º


I normally use option 4 , i create a structure with the required info
and return this if i need to return multiple values

use exception handling if you do not see anny other way, it is much
faster if you can evaluate a value and return this to take apropriate
action as to use a try catch statement or throwing errorr

regards

Michel Posseth [MCP]

I am often in the situation where I want to act on the result of a
function, but a simple boolean is not enough. For example, I may have a
function called

isAuthorised ( User, Action ) as ?????

OK, this function may return a boolean, and if this is true, then no
message back is really required, but if it fails then some supporting
message needs to be returned to the calling code. As I see it there
are a few options.

1.) Throw an exception with the message in ( But this tends to slow
down execution a little ?? )

2.) Return an enumeration type, but this is a little cumbersome
because it means I have to define all my possible return combinations
against a number, which could become messy.

3.) Add a third parameter called message which can be set to any error
message returned.

4.) Return a structure which contains a boolean and a string
describing the result.


Can I ask what you guys normally do in this situation, what is best
practice, pros and cons etc.


Thanks

Mr N

 

[Mitchell S. Honnert]

Hello Mr Newbie. This reply may be a bit late to the game, but I thought
I'd reply to give a different perspective. Especially considering your
acceptance of option 4. Personally, I will use option 4 in some situations,
but if the function is going to perform error checking i.e. it could
potentially return some specialized error information, then I would go with
Option 1. For example, if you have the following function...

Public Function IsAuthorised (userID as String, action as UserAction) As
Boolean

....the functionality of this function is self-evident. Some new guy looking
at your code is going to say "Hmm, so I pass in a UserID and a UserAction
enum and I can get back a simple True/False? Cool!" If the IsAuthorised
function can't connect to the database or some other "exceptional" situation
arises, then you can throw a customized exception. So what that the
execution is going to be slowed down a little? By definition, if you are
throwing an exception something pretty bad is happening and the few
additional milliseconds is the least of your worries!

In my mind, one of the best things about structured error handling (i.e.
Try/Catch and all that) is that you can keep the signature and return value
of your method clean of all the clutter associated with error handling. You
don't have to *pollute* your method definitions for the sake of error
handling. Depending on how much error checking is done, there can be a
bunch of values that could be returned to the calling method under error
conditions. All of these error data clutter can be kept out of the
definition of the function by using exceptions.

For example, say you had three types of error conditions that could happen
during the IsAuthorised function, each with their own combination of return
codes, error numbers, error messages, etc. Would you really want to add
each one of these possible error data to the signature of your function as
ByRef parameters or as generic properties to some specialized return
Structure? Wouldn't it be better if there was some way to associate each
piece of error data to the specific type of error that the data relates to?
Wait! There *is* a way! They're called Exceptions! ;-)

If you had three customized exceptions that the IsAuthorised function could
throw, you could associate the "ReturnCode", "ErrorNumber", or
"ErrorMessage" data as properties to the exception class to which it was
associated instead of just placing them willy-nilly in the signature or in a
return struct.

Personally, I will on occasion use customized structures for use as the
return types of functions, but I would never include error information of
this kind in structure or for that matter in a ByRef parameter. That's what
exceptions are for.

HTH

- Mitchell S. Honnert

 

[Mr Newbie]

Thanks for you reply.

OK, but this function will/may often return false as a result, this is not
something *Exceptional* no pun intended, but is simply a situation where the
user is not authorised to perform an action. In such a case the appropriate
UI action is required such as diabling a menu option or feeding back a
literal error message to the user, in this case an exception is not really
correct in my opinion.

 

[Cor Ligthert [MVP]]

Mr Newbie,

I hardly see the need for more than one return value.

It is often the a first thought of a Newbie that it is needed, however there
is seldom need for more as return than one value or object (or nothing).

Because that you did not give a proper sample, however just one that proves
what I wrote above, I assume that this question is in the scope of a Newbie.

It probably makes a program soon to spaghetti if you return more.

Just my thought,

Cor

 

[Mitchell S. Honnert]

OK, but this function will/may often return false as a result, this is not

something *Exceptional* no pun intended, but is simply a situation where
the user is not authorised to perform an action.

Right. I think we're saying the same thing. This is your function...

Public Function IsAuthorised (userID as String, action as UserAction) As
Boolean

It just returns a Boolean value. Neither of the possible return values,
True or False, are exceptional. They're just the answer to whether the User
is authorized to perform a particular action. It would only be in the case
of the *failure* of the system to determine the authorization that an
exception would be required. For example, if you had to make a call to the
database to get the authorization, but the database was not available, that
you might want to return an ErrorNumber and an ErrorMessage to the calling
procedure.

What I'm suggesting is that in this situation, you shouldn't create ByRef
parameters for ErrorNumber and ErrorMessage nor should you create a custom
Structure (containing IsAuthorized, ErrorNumber, and ErrorMessage
properties) to use as the return value of IsAuthorized function. In my
opinion this would needlessly complication the definition of the function.
It's much simpler to leave the function as defined above and, if you do get
a database error, pass the ErrorNumber and ErrorMessage values back as
properties of a customized ApplicationException.

- Mitchell S. Honnert

 

[Mr Newbie]

Yes but . . . . .

There are various reasons why someone may not be authorised to perform an
action. It is useful to give the user more information regarding the denial
of servic which is specific to a particular scenario.

 

[Mr Newbie]

Yes but . . . . .

There are various reasons why someone may not be authorised to perform an
action. It is useful to give the user more information regarding the denial
of servic which is specific to a particular scenario.

 

[Mitchell S. Honnert]

There are various reasons why someone may not be authorised to perform an

action. It is useful to give the user more information regarding the
denial of servic which is specific to a particular scenario.

OK...good point. So, there are times when you want to return more
information from a Function than just True or False. Fair enough. In that
case, use an enum or a custom structure. But I still hold to my opinion
that the error/exception information should not be in these return values.
So, just because you're creating a custom struct to use as the return value
of a function "anyway", it's not a good enough reason to put the error
information in the struct as well. If, for example, a user is not
authorized to perform an action because the current date is greater than
their employee termination date or because they just haven't been granted
access to that action, the function won't *fail*. It will successfully
return a *negative* result.

Again, it would only be if the IsAuthorized function failed to determine the
authorization that it would throw a customized exception containing
pertinent information about the error. So, ask yourself "Does this
information I'm passing out of the function relate to the successful
completion of its code?" If the answer is "Yes", then use the return value,
using whatever data type is appropriate for the returned information. But
if the answer to the question "Does the information I'm passing out relate
to the failure of the code to execute?" is "Yes", then use an Exception.

I use these same rules as much as I can and I find that my interfaces are
very clean and easily understood.

- Mitchell S. Honnert

 

[Mr Newbie]

So, ask yourself "Does this information I'm passing out of the function

relate to the successful completion of its code?" If the answer is "Yes",
then use the return value, using whatever data type is appropriate for the
returned information. But if the answer to the question "Does the
information I'm passing out relate to the failure of the code to execute?"
is "Yes", then use an Exception.

This answers my question. Thanks for the debate , good dialog.