Communicating the Reason for Method Failure
-
I have a method that could fail for a number of reasons, e.g. an invalid directory, a file not found in that directory, or an entry not found in that file. It's crossed my mind to throw different exceptions for the first two, and return null for the last, but this is not a good practice application of exceptions. My next alternative is to return null for any failure, but this makes unit testing the individual failures difficult. My third option is to return null for any failure, and set an ErrorMessage property on the class. If the method returns null, the caller can read this property and test/report on the error.
-
I have a method that could fail for a number of reasons, e.g. an invalid directory, a file not found in that directory, or an entry not found in that file. It's crossed my mind to throw different exceptions for the first two, and return null for the last, but this is not a good practice application of exceptions. My next alternative is to return null for any failure, but this makes unit testing the individual failures difficult. My third option is to return null for any failure, and set an ErrorMessage property on the class. If the method returns null, the caller can read this property and test/report on the error.
Hi Brady, IMO you should come up with satisfactory functional specs first, independent of future implementation and/or testing concerns. Once the specs are cast, you can worry about implementing and testing. You shouldn't burden the user with a more difficult API just because that makes testing easier, should you? So, will the class user want exceptions? will he be happy with a null return and the need to check something else to find what went wrong? :)
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
-
Hi Brady, IMO you should come up with satisfactory functional specs first, independent of future implementation and/or testing concerns. Once the specs are cast, you can worry about implementing and testing. You shouldn't burden the user with a more difficult API just because that makes testing easier, should you? So, will the class user want exceptions? will he be happy with a null return and the need to check something else to find what went wrong? :)
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
Luc Pattyn wrote:
So, will the class user want exceptions? will he be happy with a null return and the need to check something else to find what went wrong?
The class use is me. :) I'd prefer the latter, but was wondering if anyone had any caveats with that approach.
-
Luc Pattyn wrote:
So, will the class user want exceptions? will he be happy with a null return and the need to check something else to find what went wrong?
The class use is me. :) I'd prefer the latter, but was wondering if anyone had any caveats with that approach.
Brady Kelly wrote:
The class use is me
I thought as much, but it is rather irrelevant.
Brady Kelly wrote:
but was wondering if anyone had any caveats
none here. It is somewhat similar to the Parse/TryParse situation. They first offered Parse only, which throws whenever it feels like doing so. Then came TryParse which doesn't tell you anything, except it returns a success flag. I sometimes return a string, null=OK, non-null=error message (one step better than the old error number, 0=OK, negative=error; unless you need to check for a specific error that is). :)
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
-
I have a method that could fail for a number of reasons, e.g. an invalid directory, a file not found in that directory, or an entry not found in that file. It's crossed my mind to throw different exceptions for the first two, and return null for the last, but this is not a good practice application of exceptions. My next alternative is to return null for any failure, but this makes unit testing the individual failures difficult. My third option is to return null for any failure, and set an ErrorMessage property on the class. If the method returns null, the caller can read this property and test/report on the error.
Generally I'd go with throwing on any failure - it definitely leads to cleaner code (especially with errors bubbling up the stack and being handled at a convenient place). How you define "failure" then determines the behaviour. "Entry not found in that file" would depend for me on your model. If every client must have a phone number then GetPhoneNumber(Client) should throw if there isn't one in the file. Either you are throwing an ArgumentException for an invalid client, or you are throwing because there is no phone number for the client - and *something* went wrong, which needs to be fixed. If they might not have a phone number then returning null to indicate "none" is probably appropriate. If it returns null when it detects an error, then you are moving the error detection to the client code, which is kinda silly. Theres probably lots of "client" code for the library - and this means you are duplicating a bunch of code. It also means you have created some pretty close coupling as well. Whatever you do, make sure its clearly documented.
Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.
Entanglar: .Net game engine featuring automatic networking and powerful HLSL gfx binding. -
I have a method that could fail for a number of reasons, e.g. an invalid directory, a file not found in that directory, or an entry not found in that file. It's crossed my mind to throw different exceptions for the first two, and return null for the last, but this is not a good practice application of exceptions. My next alternative is to return null for any failure, but this makes unit testing the individual failures difficult. My third option is to return null for any failure, and set an ErrorMessage property on the class. If the method returns null, the caller can read this property and test/report on the error.
If the conditions are exceptional then using exceptions is best practice. If they are not exceptional then you might in some way encapsulate the problem, e.g., the result class, a success/failure flag and optional failure message string. This could be the messaging parameter rather than returning null.
-
If the conditions are exceptional then using exceptions is best practice. If they are not exceptional then you might in some way encapsulate the problem, e.g., the result class, a success/failure flag and optional failure message string. This could be the messaging parameter rather than returning null.
I have to return something thought, and null is ideal, even if I move away from the client checking for a null return in favour of them checking a success flag or non-null error message, or one and the same.