For example if you pass a car into a sub that makes use of a car who should be checking for null references?
Should I even bother wrapping this code in the below if statement? It seems quite redundant, obviously I could have given a better example because I can't catch the exception and handle it in any way.
Or should I just let the exception bubble up to the caller?
For example:
Public Sub CarService(ByVal car As ICar)
If car IsNot Nothing Then
'do logic here
Else : Throw New ArgumentNullException
End If
End Sub
Throwing a NullReferenceException
yourself is actually pointless. As this is
null
) and You should however, arguably at least for the public API surface, check for null references and throw an ArgumentNullException
.
Public Sub CarService(ByVal car As ICar)
If car Is Nothing Then
Throw New ArgumentNullException("car")
End If
' do logic here
End Sub
Or look into Code Contracts .
I think it's a good idea since you prevent the code to be unpredictable. Since the exception depends on the following code and can change with it. With your code you know where and what exception can be thrown.
The only thing you should think about is what exception you should use or even create a own one. Since NullReference seems a little bit misplaced.
I guess it depends on the scenario. There are cases when null
is a valid value to pass to a method. If it's not then you need to weigh how much logic would occur before the code would reach the null
object. If nothing significant happens until that point then you can simply let it bubble up. If you do make significant operations before using that object then it's worth checking it right when you enter the method. Also if you have more than one object then the caller would not know which one caused the issue so you might throw the exception yourself, adding a proper error message.
Its up to you.
If NULL
s are a part of your logic, then handle it inside your CarService
method . For eg., in your code a NULL
car may mean its an unknown car in which case you will have to write the logic for it.
You should throw the exception if you are not supposed to pass a NULL
. That way the edge case will be handled at the caller side. For instance, if your code does something like this:
Public Sub CarService(ByVal car As ICar)
car.ToString();
End Sub
In such cases explicitly throwing error makes sense which will be consistent throughout framework.
In my opininion throwing the NullReferenceException yourself is nonsense (CLR will do it for you). But on the other hand throwing the ArgumentNullException is a good practice for me. If error occurs, you know exactly where the problem is and which parameter cannot be null. To save time writting such ever-repating code I use macros in ReSharper (no problem to get under 2 seconds).
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.