-2

I have a method, that always has to return an object of type MyType. If it returns null it is because I don't have the needed information to return a value.

So I was thinking that a posibility it is to throw an argument exception if I don't have the needed information.

Another solution, it is to return a tuple, first item null or the object as result. The second item a string, null if I can return the value or a string with the reason why it is null.

I was consideration this second option, because I guess it is more versatile, who calls this method, if get a null, can know the reason of why it is null and don't need to handle the exception, that requieres more code. Also, if it is called in the UI layer, it can tell the user what information it is needed.

An exception it is more expensive if it is thrown, and also, from a point of view, I considerate the exception the way to handle something that I can't control in another way, but in this case I can know in advance if I have the needed information or not from the user, so it is not something unexpected like if I try to load a file and the file doesn't exist, for example, or try to connect to a network resource and the network is down.

Also, argument exception it is a generic exception, if I want to show to a user a understanding message but also I want a more detailed message for the developer, it is more complex code.

So I was wondering if really it is a bad idea to return a tuple or it is better to throw an exception.

I think a touple can be very usefull, because it can return the value of the method, but also can provide aditional information in another items.

Álvaro García
  • 18,114
  • 30
  • 102
  • 193
  • 1
    Short answer - it depends. Is it more like `Parse` (i.e. should throw exception) or `TryParse` (should return bool and out, or alternatively Tuple)? Either is _defensible_ - which is _expected_ depends on context and good naming. – mjwills Jul 13 '20 at 14:33
  • 1
    `so it is not something unexpected like if I try to load a file and the file doesn't exist, for example, or try to connect to a network resource and the network is down.` Does the framework have the same view on this as you? https://learn.microsoft.com/en-us/dotnet/api/system.io.file.readalltext?view=netcore-3.1 – mjwills Jul 13 '20 at 14:34
  • 1
    `but also can provide aditional information in another items.` An exception can have additional properties to also provide this additional information. – mjwills Jul 13 '20 at 14:35
  • 1
    There is also an option to return `bool` and have one or more `out` parameters. But anyhow all this topic is highly opinion-based, sorry. All methods are working, some are better at specific scenarios. Do what you think is good based on your current experience and refactor later. – Sinatr Jul 13 '20 at 14:55

1 Answers1

1

This is a variant on the Return codes vs exception discussion.

I would recommend using a specialized type rather than just a plain tuple. This should either have a value, or a string/error code. This should force the caller to handle at least one case, for example by having OnSuccess(Action<T>) and OnFail(Action<string) methods. See Result of T for an example

If this is preferable to exceptions somewhat depend on if failure is expected or not. I think it is appropriate for something like a Parse-method. For reading a file I would prefer exceptions since reading the file can fail at any time for many possible reasons. I.e. a result object fits best with a functional style.

JonasH
  • 28,608
  • 2
  • 10
  • 23