locked
Method Return types: object vs string/bool RRS feed

  • Question

  • User1369388664 posted

    Not sure if this is the correct place for this question so I apologize if I chose poorly ...


    One thing that can kinda grind my gears is exactly what type of value to return out of my methods.  If I'm returning an object, then it's pretty straight-forward.  However, if I'm just trying to return whether or not the method was successful or not, what's the best option?  Sure ... bool seems obvious - but what if you need to debug or get some additional details out of the method than just "yes/no"?  Well that's where a string becomes more obvious, right?  You can leave it empty to say that the method was successful or chock it full of details in the case of an error.  But this can make it less intuitive to others who may have to run your functions and it also jumbles up everything you wanted to pass back into one large string.  Not extremely usable.


    To combat these issues, I created a class called FunctionResult which has the following properties:

    1.  WasSuccessful (bool)

    2.  ErrorCode (string)

    3.  StackTrace (string)

    4.  DisplayMessage (string) - Just a customizable text where you can put "user friendly" messages that could be used as the text for error messages, validator messages, etc.

    5.  ReturnObject (object) - In the case that you want to use a FunctionResult and also pass back an object (without using out parameters) then you could use this for that.


    This has gotten me around many of my concerns but one potential issue that has been brought up is whether this adds overhead to the function because it's now passing a full object as opposed to a simple variable.


    Can anyone speak from experience as to how much of a cost is associated with passing around something like this and what caveats I may fall into along the way with it?  Also, any other ideas/critiques are always welcome.


    TIA.


    Thursday, May 27, 2010 9:26 AM

Answers

  • User-389939489 posted

    putts:

    > I created a class called FunctionResult which has the following properties:

    I would agree with Menno: there can be exceptions, but in most cases you would just implement a proper exception management pattern.

    > 5.  ReturnObject (object)

    I'd use generics...

    > whether this adds overhead to the function because it's now passing a full object as opposed to a simple variable.

    An object is passed by reference, so that's quite not an issue at all. IMO the point is that the memory management differences between reference- and value-types, or the boxing/unboxing issues, or the overhead of filling in a structure rather than returning some simple result, etc., while important to any serious .Net programmer, are practically insignificant in your specific case: i.e. you'd much better focus on implementing a proper design.

    > Can anyone speak from experience as to how much of a cost is associated with passing around something like this and what caveats I may fall into along the way with it?  Also, any other ideas/critiques are always welcome.

    Read the manual! I have mentioned few basic keywords in my preceeding paragraph.

    HTH,

    -LV

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, May 27, 2010 12:08 PM

All replies

  • User560403387 posted

    The return type of your methods should only ever be whatever you want to return from your method. If an error occurs you throw an exception; that's what they're for.
    Look at the .NET framework: the only methods that return a "WasSuccessful" are methods like int.TryParse . Other methods will throw an exception.

    Your system would require other developers to check if an operation was succesful every time. If an exception is thrown, you cannot ignore it, and if not handled, it will be logged in the Windows event log. Don't circumvent exceptions; embrace them.

    Menno

    Thursday, May 27, 2010 11:19 AM
  • User-389939489 posted

    putts:

    > I created a class called FunctionResult which has the following properties:

    I would agree with Menno: there can be exceptions, but in most cases you would just implement a proper exception management pattern.

    > 5.  ReturnObject (object)

    I'd use generics...

    > whether this adds overhead to the function because it's now passing a full object as opposed to a simple variable.

    An object is passed by reference, so that's quite not an issue at all. IMO the point is that the memory management differences between reference- and value-types, or the boxing/unboxing issues, or the overhead of filling in a structure rather than returning some simple result, etc., while important to any serious .Net programmer, are practically insignificant in your specific case: i.e. you'd much better focus on implementing a proper design.

    > Can anyone speak from experience as to how much of a cost is associated with passing around something like this and what caveats I may fall into along the way with it?  Also, any other ideas/critiques are always welcome.

    Read the manual! I have mentioned few basic keywords in my preceeding paragraph.

    HTH,

    -LV

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, May 27, 2010 12:08 PM
  • User1369388664 posted

    The return type of your methods should only ever be whatever you want to return from your method. If an error occurs you throw an exception; that's what they're for.
    Look at the .NET framework: the only methods that return a "WasSuccessful" are methods like int.TryParse . Other methods will throw an exception.

    Your system would require other developers to check if an operation was succesful every time. If an exception is thrown, you cannot ignore it, and if not handled, it will be logged in the Windows event log. Don't circumvent exceptions; embrace them.

    Menno


    In some instances, what you are saying is counter-effective.  You are saying ...

    "Throw the error to make sure the program handles it some way"


    However, in my case, many other programmers could be using my functions.  If they do not properly handle an error that I throw then exactly what you are hoping not to happen, happens - the error goes unhandled.  If I make this universal result object, I can actually add error tracking into it to so when I see StackTrace or ErrorCode populate, I can make some tracking/notifications action right then.  So, as long as I program my functions properly I don't have to rely on the other programmers handling (or not handling) the errors.

    If error handling really is the only major concern with this technique then I really think a standardized result object is going to the best possible option.

    Tuesday, June 1, 2010 11:26 AM