ByRef vs Return
-
I am currently building a simple database access class. I have a function GetCourse which I want to get a course object from the database. I could specify it like this:
public static function GetCourse(byval courseid as integer) as CourseAn alternative would be:public static function GetCourse(byval courseid as integer, byref course as Course) as Booleanthe two methods are only different by how they return the values. the first would returnNothingwhen it couldnt find a course (throw an exception or returnNothingwhen a database error occurred). the second function would return false when it couldnt find a course and true when it could (either throwing exceptions or returning false in the case of a db error) and it would assign the course details to the course parameter. The calling method would either check forNothingin the case of the first function or check for true/false in the case of the second function to indicate that the course could be found. I would like to hear peoples opinions on which function you would prefer and why. Or if there is a better alternative Thanks! -
I am currently building a simple database access class. I have a function GetCourse which I want to get a course object from the database. I could specify it like this:
public static function GetCourse(byval courseid as integer) as CourseAn alternative would be:public static function GetCourse(byval courseid as integer, byref course as Course) as Booleanthe two methods are only different by how they return the values. the first would returnNothingwhen it couldnt find a course (throw an exception or returnNothingwhen a database error occurred). the second function would return false when it couldnt find a course and true when it could (either throwing exceptions or returning false in the case of a db error) and it would assign the course details to the course parameter. The calling method would either check forNothingin the case of the first function or check for true/false in the case of the second function to indicate that the course could be found. I would like to hear peoples opinions on which function you would prefer and why. Or if there is a better alternative Thanks!The first method is better. You have the option of either returning Nothing or throwing an exception. A custom exception would probably be ideal, depending on your requirements of course. Your calling code would just have to check to see if the return was Nothing instead of a Boolean.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008 -
The first method is better. You have the option of either returning Nothing or throwing an exception. A custom exception would probably be ideal, depending on your requirements of course. Your calling code would just have to check to see if the return was Nothing instead of a Boolean.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008Im not sure of your point. With the second method you also have the option of throwing an exception or returning false (instead of nothing). the calling methods would be something like this (if the functions didnt handle their own exceptions 1.
try course = GetCourse(courseid) catch 'error handle end try if course is nothing then ' do something else 'do something else end if2.try if GetCourse(courseid, course) then ' do something else ' do something else end if catch ' error handle end trytheyre essentially the same as far as i can tell -
Im not sure of your point. With the second method you also have the option of throwing an exception or returning false (instead of nothing). the calling methods would be something like this (if the functions didnt handle their own exceptions 1.
try course = GetCourse(courseid) catch 'error handle end try if course is nothing then ' do something else 'do something else end if2.try if GetCourse(courseid, course) then ' do something else ' do something else end if catch ' error handle end trytheyre essentially the same as far as i can tellWhy use an extra Boolean that does that exact same thing as checking the return for an object?
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008 -
Why use an extra Boolean that does that exact same thing as checking the return for an object?
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008If the first function handled all its exceptions internally it would return nothing when there was database error or there was no course with that ID in the database. The calling method wouldnt be able to tell what really happened. With the second function you could differentiate between when the function failed or whether there just wasnt a course with that id in the database. i dont think the calling method should care about how the function failed, just whether it did or not. Allowing the functions to throw out exceptions in my opinion is a bad idea if you can just handle them internally. Yes or no?
-
If the first function handled all its exceptions internally it would return nothing when there was database error or there was no course with that ID in the database. The calling method wouldnt be able to tell what really happened. With the second function you could differentiate between when the function failed or whether there just wasnt a course with that id in the database. i dont think the calling method should care about how the function failed, just whether it did or not. Allowing the functions to throw out exceptions in my opinion is a bad idea if you can just handle them internally. Yes or no?
Kevin Brydon wrote:
If the first function handled all its exceptions internally it would return nothing when there was database error or there was no course with that ID in the database. The calling method wouldnt be able to tell what really happened.
Yes, it would if the function was written to throw an exception and not bury them internally. Depending on the requirements, the function should throw an exception if there was a problem, and let the caller (business rules) decide what to do about it.
Kevin Brydon wrote:
i dont think the calling method should care about how the function failed, just whether it did or not.
This is up to the business rules of your app, not you. Think about that. This is not a hard and fast rule in every application.
Kevin Brydon wrote:
Allowing the functions to throw out exceptions in my opinion is a bad idea if you can just handle them internally.
There are many cases where the caller needs to know HOW the operation failed and handle the failure in ceratin ways depending on the type of failure. Just returning a True/False doesn't convery any kind of useful failure information back to the caller.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008 -
I am currently building a simple database access class. I have a function GetCourse which I want to get a course object from the database. I could specify it like this:
public static function GetCourse(byval courseid as integer) as CourseAn alternative would be:public static function GetCourse(byval courseid as integer, byref course as Course) as Booleanthe two methods are only different by how they return the values. the first would returnNothingwhen it couldnt find a course (throw an exception or returnNothingwhen a database error occurred). the second function would return false when it couldnt find a course and true when it could (either throwing exceptions or returning false in the case of a db error) and it would assign the course details to the course parameter. The calling method would either check forNothingin the case of the first function or check for true/false in the case of the second function to indicate that the course could be found. I would like to hear peoples opinions on which function you would prefer and why. Or if there is a better alternative Thanks!Sending parameters by reference should generally be avoided if practically possible. As the extra boolean is totally redundant in this case, the choise is rather simple. Whether the method should return a null reference or throw an exception when it can not return an Course object, that depends on the reason. If it's normal for courses to be missing, it should return a null reference, but if the reason is that an error has occured, it should throw an exception.
Despite everything, the person most likely to be fooling you next is yourself.
-
Sending parameters by reference should generally be avoided if practically possible. As the extra boolean is totally redundant in this case, the choise is rather simple. Whether the method should return a null reference or throw an exception when it can not return an Course object, that depends on the reason. If it's normal for courses to be missing, it should return a null reference, but if the reason is that an error has occured, it should throw an exception.
Despite everything, the person most likely to be fooling you next is yourself.
Guffa wrote:
Whether the method should return a null reference or throw an exception when it can not return an Course object, that depends on the reason. If it's normal for courses to be missing, it should return a null reference, but if the reason is that an error has occured, it should throw an exception.
Another possibility which may ease things for the caller would be to have similar versions of the function, one of which will throw an exception if it can't retrieve a course for any reason, and one of which will simply return nothing in the case where it can tell that a course does not exist (it will still throw an exception in case of things like database error and so forth). An application could call the latter if it doesn't know whether the course exists, and the former when it knows that it should and will be in trouble if it doesn't. While returning 'nothing' would probably cause an exception in the latter case, having code throw a deliberate exception is probably better than causing a null-reference exception.
-
Guffa wrote:
Whether the method should return a null reference or throw an exception when it can not return an Course object, that depends on the reason. If it's normal for courses to be missing, it should return a null reference, but if the reason is that an error has occured, it should throw an exception.
Another possibility which may ease things for the caller would be to have similar versions of the function, one of which will throw an exception if it can't retrieve a course for any reason, and one of which will simply return nothing in the case where it can tell that a course does not exist (it will still throw an exception in case of things like database error and so forth). An application could call the latter if it doesn't know whether the course exists, and the former when it knows that it should and will be in trouble if it doesn't. While returning 'nothing' would probably cause an exception in the latter case, having code throw a deliberate exception is probably better than causing a null-reference exception.
supercat9 wrote:
Another possibility which may ease things for the caller would be to have similar versions of the function, one of which will throw an exception if it can't retrieve a course for any reason, and one of which will simply return nothing in the case where it can tell that a course does not exist (it will still throw an exception in case of things like database error and so forth).
More of a complement than an alternative... That could easily be accomplished with a method that gets a course and throws an exception if it's null:
Public Function GetCourseUnconditionally(courseId As Integer) As Course
Course result = GetCourse(courseId)
If result Is Nothing Then
Throw New AppplicationException("Course not found.");
End If
Return result
End FunctionDespite everything, the person most likely to be fooling you next is yourself.
-
supercat9 wrote:
Another possibility which may ease things for the caller would be to have similar versions of the function, one of which will throw an exception if it can't retrieve a course for any reason, and one of which will simply return nothing in the case where it can tell that a course does not exist (it will still throw an exception in case of things like database error and so forth).
More of a complement than an alternative... That could easily be accomplished with a method that gets a course and throws an exception if it's null:
Public Function GetCourseUnconditionally(courseId As Integer) As Course
Course result = GetCourse(courseId)
If result Is Nothing Then
Throw New AppplicationException("Course not found.");
End If
Return result
End FunctionDespite everything, the person most likely to be fooling you next is yourself.
Thanks for your answers. I've decided to get rid on my byref/boolean functions and opted for the first option. I think its the most sensible choice for my application and possibly is the best choice for most apps.