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" <he**@now.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

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]

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 º¿º
"m.posseth" <mi*****@nohausystems.nl> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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" <he**@now.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

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]

Mr Newbie wrote:

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.

--

(O)enone

[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]

"Mr Newbie" <he**@now.com> wrote in message
news:eI**************@TK2MSFTNGP14.phx.gbl...

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 º¿º
"m.posseth" <mi*****@nohausystems.nl> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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" <he**@now.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

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 º¿º


"m.posseth" <mi*****@nohausystems.nl> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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]

"Mr Newbie" <he**@now.com> wrote in message
news:eI**************@TK2MSFTNGP14.phx.gbl...

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 º¿º
"m.posseth" <mi*****@nohausystems.nl> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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" <he**@now.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
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 º¿º
"Mr Newbie" <he**@now.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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 º¿º


"m.posseth" <mi*****@nohausystems.nl> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

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]

"Mr Newbie" <he**@now.com> wrote in message
news:eI**************@TK2MSFTNGP14.phx.gbl...

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 º¿º
"m.posseth" <mi*****@nohausystems.nl> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
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" <he**@now.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
>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" <he**@now.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

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]

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.

--
Best Regards

The Inimitable Mr Newbie º¿º
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:uN**************@TK2MSFTNGP15.phx.gbl...

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" <he**@now.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

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

[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" <he**@now.com> wrote in message
news:e3**************@TK2MSFTNGP12.phx.gbl... 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.

--
Best Regards

The Inimitable Mr Newbie º¿º
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:uN**************@TK2MSFTNGP15.phx.gbl...

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" <he**@now.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...

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]

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.

--
Best Regards

The Inimitable Mr Newbie º¿º

"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:Od**************@TK2MSFTNGP14.phx.gbl...

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" <he**@now.com> wrote in message
news:e3**************@TK2MSFTNGP12.phx.gbl...

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.

--
Best Regards

The Inimitable Mr Newbie º¿º
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:uN**************@TK2MSFTNGP15.phx.gbl...

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" <he**@now.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
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]

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.

--
Best Regards

"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:uH*************@TK2MSFTNGP11.phx.gbl...

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]

> 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" <he**@now.com> wrote in message
news:uQ**************@TK2MSFTNGP12.phx.gbl... 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.

--
Best Regards

The Inimitable Mr Newbie º¿º

"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:Od**************@TK2MSFTNGP14.phx.gbl...

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" <he**@now.com> wrote in message
news:e3**************@TK2MSFTNGP12.phx.gbl...

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.

--
Best Regards

The Inimitable Mr Newbie º¿º
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:uN**************@TK2MSFTNGP15.phx.gbl...
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" <he**@now.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
>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]

> 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.
--
Best Regards

The Inimitable Mr Newbie º¿º
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:OH*************@TK2MSFTNGP12.phx.gbl...

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" <he**@now.com> wrote in message
news:uQ**************@TK2MSFTNGP12.phx.gbl...

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.

--
Best Regards

The Inimitable Mr Newbie º¿º

"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:Od**************@TK2MSFTNGP14.phx.gbl...

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" <he**@now.com> wrote in message
news:e3**************@TK2MSFTNGP12.phx.gbl...
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.

--
Best Regards

The Inimitable Mr Newbie º¿º
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:uN**************@TK2MSFTNGP15.phx.gbl...
> 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" <he**@now.com> wrote in message
> news:%2****************@TK2MSFTNGP14.phx.gbl...
>>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
>>
>
>