General Question On Handling of Function results.

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

re: General Question On Handling of Function results.

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" <here@now.com> wrote in message
news:%23FdSMfq8FHA.2036@TK2MSFTNGP14.phx.gbl...[color=blue]
>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
>[/color]

re: General Question On Handling of Function results.

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" <michelp@nohausystems.nl> wrote in message
news:%23P9Zy4s8FHA.4008@TK2MSFTNGP10.phx.gbl...[color=blue]
>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" <here@now.com> wrote in message
> news:%23FdSMfq8FHA.2036@TK2MSFTNGP14.phx.gbl...[color=green]
>>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
>>[/color]
>
>[/color]

re: General Question On Handling of Function results.

Mr Newbie wrote:[color=blue]
> Can I ask what you guys normally do in this situation, what is best
> practice, pros and cons etc.[/color]

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

re: General Question On Handling of Function results.

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" <here@now.com> wrote in message
news:eIK4syz8FHA.2192@TK2MSFTNGP14.phx.gbl...[color=blue]
> 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" <michelp@nohausystems.nl> wrote in message
> news:%23P9Zy4s8FHA.4008@TK2MSFTNGP10.phx.gbl...[color=green]
>>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" <here@now.com> wrote in message
>> news:%23FdSMfq8FHA.2036@TK2MSFTNGP14.phx.gbl...[color=darkred]
>>>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
>>>[/color]
>>
>>[/color]
>
>[/color]

re: General Question On Handling of Function results.

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" <michelp@nohausystems.nl> wrote in message
news:%23Rn7kd28FHA.2152@TK2MSFTNGP10.phx.gbl...[color=blue]
> 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" <here@now.com> wrote in message
> news:eIK4syz8FHA.2192@TK2MSFTNGP14.phx.gbl...[color=green]
>> 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" <michelp@nohausystems.nl> wrote in message
>> news:%23P9Zy4s8FHA.4008@TK2MSFTNGP10.phx.gbl...[color=darkred]
>>>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" <here@now.com> wrote in message
>>> news:%23FdSMfq8FHA.2036@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
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

re: General Question On Handling of Function results.

PS : I have started a new thread on this subject

--
Best Regards

The Inimitable Mr Newbie º¿º
"Mr Newbie" <here@now.com> wrote in message
news:%23IO41d38FHA.3048@TK2MSFTNGP10.phx.gbl...[color=blue]
> 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" <michelp@nohausystems.nl> wrote in message
> news:%23Rn7kd28FHA.2152@TK2MSFTNGP10.phx.gbl...[color=green]
>> 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" <here@now.com> wrote in message
>> news:eIK4syz8FHA.2192@TK2MSFTNGP14.phx.gbl...[color=darkred]
>>> 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" <michelp@nohausystems.nl> wrote in message
>>> news:%23P9Zy4s8FHA.4008@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" <here@now.com> wrote in message
>>>> news:%23FdSMfq8FHA.2036@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
>>>>>
>>>>
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

re: General Question On Handling of Function results.

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" <here@now.com> wrote in message
news:%23FdSMfq8FHA.2036@TK2MSFTNGP14.phx.gbl...[color=blue]
>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
>[/color]

re: General Question On Handling of Function results.

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:uNhInnE9FHA.2676@TK2MSFTNGP15.phx.gbl...[color=blue]
> 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" <here@now.com> wrote in message
> news:%23FdSMfq8FHA.2036@TK2MSFTNGP14.phx.gbl...[color=green]
>>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
>>[/color]
>
>[/color]

re: General Question On Handling of Function results.

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

re: General Question On Handling of Function results.

> OK, but this function will/may often return false as a result, this is not[color=blue]
> something *Exceptional* no pun intended, but is simply a situation where
> the user is not authorised to perform an action.[/color]
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" <here@now.com> wrote in message
news:e3TF0rE9FHA.3880@TK2MSFTNGP12.phx.gbl...[color=blue]
> 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:uNhInnE9FHA.2676@TK2MSFTNGP15.phx.gbl...[color=green]
>> 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" <here@now.com> wrote in message
>> news:%23FdSMfq8FHA.2036@TK2MSFTNGP14.phx.gbl...[color=darkred]
>>>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
>>>[/color]
>>
>>[/color]
>
>[/color]

re: General Question On Handling of Function results.

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:OdAnlfF9FHA.2040@TK2MSFTNGP14.phx.gbl...[color=blue][color=green]
>> 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.[/color]
> 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" <here@now.com> wrote in message
> news:e3TF0rE9FHA.3880@TK2MSFTNGP12.phx.gbl...[color=green]
>> 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:uNhInnE9FHA.2676@TK2MSFTNGP15.phx.gbl...[color=darkred]
>>> 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" <here@now.com> wrote in message
>>> news:%23FdSMfq8FHA.2036@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
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

re: General Question On Handling of Function results.

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]" <notmyfirstname@planet.nl> wrote in message
news:uHdNu1E9FHA.740@TK2MSFTNGP11.phx.gbl...[color=blue]
> 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
>[/color]

re: General Question On Handling of Function results.

> There are various reasons why someone may not be authorised to perform an[color=blue]
> action. It is useful to give the user more information regarding the
> denial of servic which is specific to a particular scenario.[/color]
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" <here@now.com> wrote in message
news:uQybo6R9FHA.3132@TK2MSFTNGP12.phx.gbl...[color=blue]
> 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:OdAnlfF9FHA.2040@TK2MSFTNGP14.phx.gbl...[color=green][color=darkred]
>>> 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.[/color]
>> 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" <here@now.com> wrote in message
>> news:e3TF0rE9FHA.3880@TK2MSFTNGP12.phx.gbl...[color=darkred]
>>> 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:uNhInnE9FHA.2676@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" <here@now.com> wrote in message
>>>> news:%23FdSMfq8FHA.2036@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
>>>>>
>>>>
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

re: General Question On Handling of Function results.

> So, ask yourself "Does this information I'm passing out of the function[color=blue]
> 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.
>[/color]

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:OHUGFWS9FHA.952@TK2MSFTNGP12.phx.gbl...[color=blue][color=green]
>> 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.[/color]
> 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" <here@now.com> wrote in message
> news:uQybo6R9FHA.3132@TK2MSFTNGP12.phx.gbl...[color=green]
>> 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:OdAnlfF9FHA.2040@TK2MSFTNGP14.phx.gbl...[color=darkred]
>>>> 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" <here@now.com> wrote in message
>>> news:e3TF0rE9FHA.3880@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:uNhInnE9FHA.2676@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" <here@now.com> wrote in message
>>>>> news:%23FdSMfq8FHA.2036@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
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]