If a class has a constructor which takes some value object as parameter and relies on this to do its initialization. How should it react if this object is null?
class SomeClass
{
private SomeData _data;
public SomeClass(SomeValueObject obj)
{
_data = obj.Data;
}
}
This is one example, but in general: How should a constructor act if it is given invalid parameters and therefore cannot do the construction properly? Should it just return without doing any initialization? Set the parameters to some default values? Throw an exception? Something else?
I'm sure the answer to this is "It depends", but are there any best practices etc?
A programmer should be able to assume an object was successfully created, unless an exception is raised. The type of exception depends on the argument, but should nonetheless be unchecked. The last thing you want is the constructor fail to build a valid object and not tell the caller about it.
I think using default values in a constructor is a dangerous habit.
A lot depends on your business logic. If your business logic requires SomeValueObject to be not null, meaning SomeClass could not be instantiated without SomeValueObject then the constructor should definitely throw an Exception, probably IllegalArgumentException.
Seems like this is Java, but in C++ it should definitively throw ( a std::invalid_argument even ).
See C++ FAQ Lite 17.2.
I guess that for Java it's exactly the same.
In the rare cases where throwing exceptions presents a too big of a overhead, you should return, and set a flag in the object that it didn't construct properly. Afterwards check a isValid() member function.
Throw a null argument exception.
If field is critical it should cast an exception to indicate that object shouldnt be used. If its not critical you can assign default values.
If an object can have invalid default values, then it should initialize to the default values and wait for initialization. E.g., foo.set_values(...). In this case, there should be a query of is_ready() or is_valid() to allow checking before use.
If an object can absolutely not be in an invalid data-state, then it should throw an exception.
Both of these cases are things I've encounted.
Related
So im preparing for interviews and in one of Gayle Laakmans career Cup videos a guy is writing a simple method that takes in an array and does something with it. She mentions his lack of error checking so he adds in this line like so:
public int max(int[] array) {
if (array == null)
throw new NullPointerException();
//method body
}
Is it correct to manually throw a NPE exception like this, this exception will get thrown anyway in the method body as it will use the array reference at some point.
A possible advantage to this i can see is that it separates input invalidation from the method logic being invalid and somehow creating a null reference. Otherwise it is a little confusing and maybe IllegalArgumentException would work better?
There's nothing wrong with throwing NullPointerException as soon as you enter the method instead of waiting to detect it after some processing has already been done. If the method is going to fail, it might as well fail fast.
Joshua Bloch's Effective Java recommends throwing NullPointerException over IllegalArgumentException in this situation (Item 60: Favor the use of standard exceptions).
If a caller passes null in some parameter for which null values are prohibited, convention dictates that NullPointerException be thrown rather than IllegalArgumentException.
IllegalArgumentException should be thrown when an illegal non-null value is passed in.
Also have a look at java's own utility class java.util.Objects:
public static <T> T requireNonNull(T obj,
String message)
Checks that the specified object reference is not null and throws a customized NullPointerException if it is. This method is designed primarily for doing parameter validation in methods and constructors with multiple parameters, as demonstrated below:
public Foo(Bar bar, Baz baz) {
this.bar = Objects.requireNonNull(bar, "bar must not be null");
this.baz = Objects.requireNonNull(baz, "baz must not be null");
}
Type Parameters:
T - the type of the reference
Parameters:
obj - the object reference to check for nullity
message - detail message to be used in the event that a NullPointerException is thrown
Returns:
obj if not null
Throws:
NullPointerException - if obj is null
from https://docs.oracle.com/javase/7/docs/api/java/util/Objects.html
Conclusion
Whether or not you use this utility class is another question, but it definitely shows, that the team behind the Java language intended to use NullPointerException for these purposes.
Today I encountered the following situation: ("pseudo code")
class MyClass {
public void workOnArray(Object[] data) {
for (Object item : data) {
workOnItem(item);
}
}
public void workOnItem(Object item) {
if (item == null) throw new NullPointerException();
}
}
Now if the caller calls workOnArray with an array containing null items, the caller would get a NullPointerException because of workOnItem.
But I could insert an additional check in workOnArray, in other words, the problem can be detected sooner.
(Please note that this is a trivial example, in a real life application this can be much less obvious).
On the pro side I'd say an additional check could offer more high-level diagnostic information. Also failing early is always a good thing.
On the contra side I'd ask myself "If I do that, shouldn't I also validate each and every parameter passed into the core API of my programming language and throw the exact same exceptions?"
Is there some rule of thumb when to throw exceptions early and when to just let the callee throw it?
In the case of a loop processing items like that, there's one thing that would definitely make me want to pre-validate the whole array of items first; If it would be bad for some of the items to be processed before an exception was thrown, leaving any remaining items un-processed.
Barring some sort of transaction mechanism wrapping the code, I would usually want to have some assurance that the items in the collection were valid before beginning to process them.
In this example, the workOnItem method is the one that cares whether or not item is null. The workOnArray method doesn't care whether or not items are null and so IMO shouldn't validate whether or not any items are null. The workOnItem method does care and so should perform the check.
I would also consider throwing a more appropriate exception type from workOnItem. A NullPointerException (or in C#, NullReferenceException) often indicates some unexpected flaw in the operation of a method. In C#, I would be more inclined to throw an ArgumentNullException that includes the name of the null parameter. This more clearly indicates that workOnItem can't continue because it cannot handle receiving a null argument.
The NullObjectPattern is intended to be a "safe" ( neutral ) behavior.
The idea is create an object that don't do anything ( but doesn't throw NullPointerException either )
For instance the class defined as:
class Employee {
private String name;
private int age;
public String getName(){ return name; }
public int getAge() { return age; }
}
Would cause a NullPointerException in this code:
class Other {
Employee oscar;
String theName = oscar.getName(); // NPE
}
What the NOP says, is you can have an object like this:
class NullEmployee extends Employee {
public static final Employee instance = new NullEmployee();
public String getName(){ return ""; }
public int getAge() { return 0; }
}
And then use it as the default value.
Employee oscar = NullEmployee.instance;
The problem comes, when you need to repeat the code for every class you create, then a solution would be to have a tool to created it.
Would it be feasible/reasonable/useful to create such a tool or to use it ( if existed )?
Perhaps using AOP or DI the default value could be used automagically.
To me, the Null Object pattern feels like a placebo. A real object and a null object may have completely different meanings, but act very similar. Just like a placebo, the null object will trick you into believing there's nothing wrong, but something could be very wrong.
I think it's a good practice to fail early and fail often. In the end, you'll want to distinguish between a real object and a null object somewhere, and at that point it would be no different from checking against a null pointer.
From the Wikipedia article:
The advantage of this approach over a working default implementation is that a Null Object is very predictable and has no side effects: it does nothing.
It won't point out any problems either. Think of what will happen when a null object travels all the way through your application. Then, at some point, your application expects certain behavior from the object, which the null object implementation fails to deliver. At that point your application may crash or enter an invalid state. You'll have a very hard time tracing the origin of the null object. A null pointer would have thrown an exception right at the beginning, drawing your attention directly to the source of the problem.
The only example the Wikipedia article gives, is that of an empty collection instead of null. This is a very good practice, but a lousy example of the null object pattern, because it's dealing with a collection of objects, instead of a single instance.
In short, I'm sure it's feasible to create null object implementations for all your classes, but I strongly recommend against it.
I am not sure this is a good idea.
A "nullObject" may be useful and make perfect sense in some cases, but having this for every class is an overkill. Especially because this could potentially make some bug (or gaps in analysis) very hard to diagnose.
Also, what about 3rd part libraries that return new objects? Would you put some kind of "interface" in front of these so that in case they return null you will substitute an appopriate flavour of nullObject?
You mention that you are trying to automate this - wouldn't some cases require an actual design decision to return an appropriate value?
I.e., suppose you have an Image object, and it returns a "ImageType" (an Enumeration for .gif, .jpg etc.)
In this case, the ImageNullObject should return... "IMAGETYPE.GIF"? "IMAGETYPE.UNKNOWN"? Null?
I think you are just begging to push the error conditions down a layer.
When an application asks for an object, and it is null, then you need to deal with that condition, not just hope it is ok. If the object is null, and you try to use it, you will get errors, so why force all that error checking on the rest of the code?
I'd think it would be tricky to autogenerate functional null objects. (You could of course create shells that you then go and fill in the implementation itself).
As a quick example - what is the null functionality for a method that returns an int? Should it return -1, 0, or perhaps some other value? How about something that returns a String - again, is null or "" the correct choice? For methods returning some other class - if it's one of your own classes then presumably you could use the Null Object for that class, but how would you access it? Perhaps you could make every class you write implement some interface with an accessor for the null object, but is it worth it?
Even with methods that return void, it's not always the case that the null functionality is to simply return. Some classes, for example, might need to call a method on a parent/delegate object when they've done their own thing (which in this case would be a no-op) in order to preserve the invariants of the class.
So basically - even to implement "null" behaviour, you have to be able to infer what this behaviour is, and I expect this is far too advanced for a tool to do itself. Perhaps you could annotate all your methods with something like #NullReturns(-1), and have a tool pick these up and form the null object implementation, but even that won't cover every situation and you may as well write the object directly instead of writing all its functionality in annotations.
What I'd like to see would be for a compiler to allow one to define the behavior of a null object with a statically-defined type. For example, if 'Foo' is of class 'bar':
Class Bar
Dim Value as Integer
Function Boz() As Integer
Return Value
End Sub
Sub Nothing.Bar() As Integer
Return -9
End Sub
End Class
attempting to evaluate Foo.Bar() would yield Foo.Value if Foo is non-null, or else -9. One could achieve some such functionality using extension methods, but that seems a little icky.
Except for testing, I generally call this type of concept coding for Slop. It's the opposite of fail-fast, you are postponing any chance of locating a state you did not code for.
The main point here is why is it possible for your object to return a value that's not in the method's contract? When you designed and coded the method's contract, you either said it could or couldn't return null, right? So if you can return null, it's important. If you can't return null, it's important.
Also, If the object reference you are using can be null then that's a significant value and you shouldn't EVER be dipping into code that might access that object's methods.
On top of that, use final/constant/invariant variables every chance you get and (at least with OO languages, isolate your data behind a constructor that can insure correct state). If an immutable object correctly sets up it's variables, it's impossible for those variables to return invalid values.
Except for emergency patches and testing I honestly can't see any excuse for this kind of coding except "I don't understand the code and I think this isn't working right but I don't want to try to understand it"--which is not, IMO, a valid excuse for an engineer.
Please tell me why the constructor does not return any value. I want a perfect technical reason to explain to my students why the constructor does not have any return type.
What actually happens with the constructor is that the runtime uses type data generated by the compiler to determine how much space is needed to store an object instance in memory, be it on the stack or on the heap.
This space includes all members variables and the vtbl. After this space is allocated, the constructor is called as an internal part of the instantiation and initialization process to initialize the contents of the fields.
Then, when the constructor exits, the runtime returns the newly-created instance. So the reason the constructor doesn't return a value is because it's not called directly by your code, it's called by the memory allocation and object initialization code in the runtime.
Its return value (if it actually has one when compiled down to machine code) is opaque to the user - therefore, you can't specify it.
Well, in a way it returns the instance that has just been constructed.
You even call it like this, for example is Java
Object o = new Something();
which looks just like calling a "regular" method with a return value
Object o = someMethod();
How is a constructor supposed to return a return value? The new operator returns the newly created instance. You do not call a ctor, newdoes it.
MyClass instance = new MyClass();
If the ctor would return a value, like so:
public int MyClass()
{
return 42;
}
Where would you receive the integer?
(I'm biased towards C++, so regarding other languages, take this with a grain of salt.)
Short answer: You don't want to have to explicitly check for success for every single object construction in your code.
Somewhat longer answer: In C++, constructors are called for dynamically as well as for globally and automatically allocated objects. In this code
void f()
{
std::string s;
}
there is no way for the constructor of s (std::string::string()) to return any value. Either it succeeds - then we can use the object, or it throws an exception - the we never get a chance to try to use it.
IMO, that's the way it should be.
A constructor is some method automatically called when you initialize a new instance of an object.
This method is there if you need to initialize your object to a given state and run few default methods.
Actually you can imagine the constructor always return the instance of the object created that would be a good image.
When you call a constructor the return value is the new object:
Point pt = new Point(1,2);
But within the constructor itself, you're not actually creating and returning the object; it's been created before your code starts, you're just setting up the initial values.
Point::Point(int x, int y) {
this->x = x;
this->y = y;
}
The lack of a return type reflects the fact that constructors are used differently than other functions. A return type of null, while technically accurate, doesn't reflect well the fact that the code is used as if it returns an object. However, any other return type would indicate that your code is supposed to return something at the end, which is also incorrect.
Constructor doesn’t return anything not even Void. Though some of the answers have mentioned that Constructor do return reference to the newly created object , which is not true. It’s the new operator that returns the object.
So Why constructor doesn’t return any value
Because its not supposed to return anything. The whole purpose of constructor is to initialize the current state of the object by setting the initial values.
So Why doesn’t it even return Void
This is actually a Design constraint which has been placed to distinguish it from methods. public void className() is perfectly legal in java but it denotes a method and not a constructor. To make the compiler understand that it’s a constructor , it requires a way to distinguish it.
all answers are biased towards C++/Java. there is no reason a constructor does not return a value other than the language design.
look at a constructor in a broader sense: it is a function which constructs a new object. you can write perfectly valid constructors in C:
typedef struct object object;
int object_create( object **this );
this is perfect OOP in C and the constructor returns value (this can also be called a factory, but the name depends on the intention).
however, in order to create an object automatically (to satisfy some type cast, or conversion for example), there have to be some rules defined. in C++, there is an argument-less constructor, which is inferred by the compiler if it is not defined.
the discussion is broader than what we think. Object Oriented Programming is a name which describes a way of thinking about programming. you can have OO in almost any language: all you need is structures and functions. mainstream languages like C++ and Java are so common that we think they define "the way". now look at the OO model in Ada: it is far from the model of C++ but is still OO. i am sure languages like Lisp have some other ways of doing OO.
One point that hasn't yet been discussed is that the constructor of class "foo" must be usable not only when creating instances of foo, but also when creating instances of classes derived from foo. In the absence of generics (which weren't available when Java, C++, or .net were designed) there would be no way for foo's constructor to return an object of any derived class. Therefore, what needs to happen is for the derived-class object to be created via some other means and then made available to foo's constructor (which will then be able to use the object in question as a foo when doing its initialization).
Even though the VM implementation of a constructor isn't to return any value, in practice it kind of does - the new object's reference. It would then be syntactically weird and / or confusing to be able to store one or both of the new object's reference and an additional return value in one statement.
So the reason the constructor doesn't return a value is because it's not called directly by your code, it's called by the memory allocation and object initialization code in the runtime. Its return value (if it actually has one when compiled down to machine code) is opaque to the user - therefore, you can't specify it.
Constructor is not directly called by the user's code. It's called by the memory allocation and object initialization code in the run time. Its value is not visible to the user.
In case of C#, the syntax for declaring object is :
classname objectname= new constructor();
According to this line, if we are using assignment operator(=) then it should return some value. But the main objective of a constructor is to assign values to variables, so when we use a new keyword it creates instance of that class, and constructor assigns values to the variable for that particular instance of object, so constructor returns assigned values for that objects's instance.
We can not call constructors independently. Instead they are automatically called whenever objects are created.
Ex:
MyDate md = new Mydate(22,12,2012);
In above example new will return a memory location which will be held by md, and programatically we can not return multiple values in single statements.
So constructors can not return anything.
From what I know about OO design methodologies, I would say the following:
1)By allowing a constructor to return a value, framework developer would allow the program to crash in an instant where the returned value is not handled. To keep the integrity of the program workflow, not allowing a return value from the initialization of an object is a valid decision. Instead, language designer would suggest/force the coders to use getter/setter - access methods.
2)Allowing the object to return a value on initialization also opens possible information leaks. Specially when there are multiple layer or access modifications applied to the variables/methods.
As you aware that when object is created constructor will be automatically called So now imagine that constructor is returning an int value. So code should like this...
Class ABC
{
int i;
public:
int ABC()
{
i=0;
return i;
}
.......
};
int main()
{
int k= ABC abc; //constructor is called so we have to store the value return by it
....
}
But as you aware that stament like int k= ABC abc; is not possible in any programming language. Hope you can understand.
i found it helpful
This confusion arises from the assumption that constructors are just like any other functions/methods defined by the class. NO, they are not.
Constructors are just part of the process of object creation. They are not called like other member functions.
I would be using Java as my language in the answer.
class SayHelloOnCreation {
public SayHelloOnCreation() {
System.out.println("Hello, Thanks For Creating me!");
}
}
class Test {
public static void main(String[]args) {
SayHelloOnCreation thing = new SayHelloOnCreation(); //This line here, produces an output - Hello, Thanks For Creating me!
}
}
Now let us see what is happening here. in java, we use the new keyword to create an instance of a class. And as you can see in the code, in the line, SayHelloOnCreation thing = new SayHelloOnCreation();, the expression after the assignment operator runs before assignment is done. So using the keyword new, we call the constructor of that class (SayHelloOnCreation()) and this constructor creates an object on the Java Heap. After the object is created, a reference to that object is assigned to the thing reference of type SayHelloOnCreation.
The point that I am trying to keep here is that if constructors were allowed to have a return type, Firstly the strongly typed nature of the language would be compromised (Remember I am speaking about Java here).
Secondly, an object of class SayHelloOnCreation is created here so by default I guess the constructor returns a reference of the same type, to avoid ClassCastException.
A method returns the value to its caller method, when called explicitly. Since, a constructor is not called explicitly, who will it return the value to. The sole purpose of a constructor is to initialize the member variables of a class.
I know two approaches to Exception handling, lets have a look at them.
Contract approach.
When a method does not do what it says it will do in the method header, it will throw an exception. Thus the method "promises" that it will do the operation, and if it fails for some reason, it will throw an exception.
Exceptional approach.
Only throw exceptions when something truly weird happens. You should not use exceptions when you can resolve the situation with normal control flow (If statements). You don't use Exceptions for control flow, as you might in the contract approach.
Lets use both approaches in different cases:
We have a Customer class that has a method called OrderProduct.
contract approach:
class Customer
{
public void OrderProduct(Product product)
{
if((m_credit - product.Price) < 0)
throw new NoCreditException("Not enough credit!");
// do stuff
}
}
exceptional approach:
class Customer
{
public bool OrderProduct(Product product)
{
if((m_credit - product.Price) < 0)
return false;
// do stuff
return true;
}
}
if !(customer.OrderProduct(product))
Console.WriteLine("Not enough credit!");
else
// go on with your life
Here I prefer the exceptional approach, as it is not truly Exceptional that a customer has no money assuming he did not win the lottery.
But here is a situation I err on the contract style.
Exceptional:
class CarController
{
// returns null if car creation failed.
public Car CreateCar(string model)
{
// something went wrong, wrong model
return null;
}
}
When I call a method called CreateCar, I damn wel expect a Car instance instead of some lousy null pointer, which can ravage my running code a dozen lines later. Thus I prefer contract to this one:
class CarController
{
public Car CreateCar(string model)
{
// something went wrong, wrong model
throw new CarModelNotKnownException("Model unkown");
return new Car();
}
}
Which do style do you use? What do you think is best general approach to Exceptions?
I favor what you call the "contract" approach. Returning nulls or other special values to indicate errors isn't necessary in a language that supports exceptions. I find it much easier to understand code when it doesn't have a bunch of "if (result == NULL)" or "if (result == -1)" clauses mixed in with what could be very simple, straightforward logic.
My usual approach is to use contract to handle any kind of error due to "client" invocation, that is, due to an external error (i.e ArgumentNullException).
Every error on the arguments is not handled. An exception is raised and the "client" is in charge of handling it. On the other hand, for internal errors always try to correct them (as if you can't get a database connection for some reason) and only if you can't handle it reraise the exception.
It's important to keep in mind that most unhandled exception at such level will not be able to be handled by the client anyway so they will just probably go up to the most general exception handler, so if such an exception occurs you are probably FUBAR anyway.
I believe that if you are building a class which will be used by an external program (or will be reused by other programs) then you should use the contract approach. A good example of this is an API of any kind.
If you are actually interested in exceptions and want to think about how to use them to construct robust systems, consider reading Making reliable distributed systems in the presence of software errors.
Both approaches are right. What that means is that a contract should be written in such a way as to specify for all cases that are not truly exceptional a behavior that does not require throwing an exception.
Note that some situations may or may not be exceptional based upon what the caller of the code is expecting. If the caller is expecting that a dictionary will contain a certain item, and absence of that item would indicate a severe problem, then failure to find the item is an exceptional condition and should cause an exception to be thrown. If, however, the caller doesn't really know if an item exists, and is equally prepared to handle its presence or its absence, then absence of the item would be an expected condition and should not cause an exception. The best way to handle such variations in caller expectation is to have a contract specify two methods: a DoSomething method and a TryDoSomething method, e.g.
TValue GetValue(TKey Key);
bool TryGetValue(TKey Key, ref TValue value);
Note that, while the standard 'try' pattern is as illustrated above, some alternatives may also be helpful if one is designing an interface which produces items:
// In case of failure, set ok false and return default<TValue>.
TValue TryGetResult(ref bool ok, TParam param);
// In case of failure, indicate particular problem in GetKeyErrorInfo
// and return default<TValue>.
TValue TryGetResult(ref GetKeyErrorInfo errorInfo, ref TParam param);
Note that using something like the normal TryGetResult pattern within an interface will make the interface invariant with respect to the result type; using one of the patterns above will allow the interface to be covariant with respect to the result type. Also, it will allow the result to be used in a 'var' declaration:
var myThingResult = myThing.TryGetSomeValue(ref ok, whatever);
if (ok) { do_whatever }
Not quite the standard approach, but in some cases the advantages may justify it.