Ernesto Arroyo wrote:Although using the constructor is valid, this other solution is better because we can return null:
In general, I don't think being able to return null makes it better. If I'm asking for an object, I expect to get that object. If there's a problem, I want to be made aware of it by an exception, so I can deal with it outside of my happy-path code. I don't want to have to check for null.
And in this particular case, it's almost certainly wrong to return null. If we're passing an age > 99, then we've violated a precondition of creating one of these objects, which is a bug, and which therefore should result in an unchecked exception.
I can think of numerous occasions where I have used the Factory pattern rather than rely upon an exception. I would use an exception if the condition is indeed exceptional, but use a Factory if failure was something that could be expected and then an alternate approach taken.
Again, if it's an exceptional condition that needs the stack to unwind, I'd throw an exception. If I just wanted to continue processing in the same method, I'd use a Factory that returns null on failure. An if statement is a lot clearer than a try-catch block that simply catches the exception and continues on its merry way.
Bear Bibeault wrote:Again, if it's an exceptional condition that needs the stack to unwind, I'd throw an exception.
I'd certainly consider the caller passing me a param that violates a precondition to be an exceptional condition.
If I just wanted to continue processing in the same method, I'd use a Factory that returns null on failure. An if statement is a lot clearer than a try-catch block that simply catches the exception and continues on its merry way.
True, but an if statement is less clear than a proper try catch block that properly handles the exception, and is less clear than simply letting the unchecked exception bubble up to the caller. Not having to check return values to know if a call succeeded is pretty much the driving force behind the existence of exceptions, after all. (And I'm sure you know this, so I expect that we just have two very different mental pictures of what the underlying assumptions are that define the context we're talking about.)
Jeff Verdegan wrote:I'd certainly consider the caller passing me a param that violates a precondition to be an exceptional condition.
In this case perhaps. But it's just a toy program so there's really nothing to say about it.
In other cases, not so much. Business logic could dictate that when a failure occurs, a reasonable default alternate is to be used. Also, at least in web apps, validation errors are rarely handled by exceptions.
My point is that I'm not saying that one way or the other is better. I'm saying that it depends upon the circumstances.
True, but an if statement is less clear
I disagree with the absoluteness of this statement. Where the logic is representing a conditional, an if statement is usually more clear. And I say usually, because there might be rare circumstances where it is not.
Remember, I'm not talking about cases where the stack needs to be unwound. I'm talking about cases where upon failure, processing should continue, perhaps taking a different path.
I expect that we just have two very different mental pictures of what the underlying assumptions are that define the context we're talking about.)
Again, that's my point. Without any assumptions or context, it's impossible to say that one approach is better than the other.
Not only I prefer return null but I could prefer to return a NullPerson (Null Object Pattern)
It depends but a NullPerson who does nothing can be (or cannot, it depends) a great design.
So let me see if I understand this: You have this hypothetical factory method for creating a hypothetical Person or something like that, and, since you're just playing around for educational purposes, you've added the precondition that a Person's age cannot be > 99. And presumably in this hypothetical scenario you will have documented this precondition, so that any caller of your method knows that age must be <= 99 (and, I would assume, >=0).
So now, when a caller of your method has a bug whereby he's passing a value that violates the precondition, rather than use the mechanism that is specifically intended to handle that situation, you consider it better to return null--which he then has to explicitly check for in his "happy-path" code--or return a NullPerson, which he still has to check for if he wants to know if he's done anything wrong, or which he can go on using, with the mistaken impression that he has created a valid Person object of age > 99?
I'd love to hear a technical justification for that.
Or if that's not what you mean, I'd love to hear which of my assumptions are wrong.
Well, one of my incorrect assumptions was that the person I was responding to was the OP. Apologies for the mixup.
Joined: Mar 21, 2012
Most of the posts are not from me ,who started the thread
I am just trying to learn and nobody answer why my code doesnt print the IllegalArgumentException,the code from the second post
Why should it print the exception? What I would expect is that the exception is not caught anywhere, so it causes your application to terminate. It's possible that whatever you are using to run your application might display that application's stack trace, but as far as I remember you haven't said anything about how you are running it.
Ditch the IDE for now and learn how to do things for real from the command line. IDEs, in my opinion, make great smart editors, but to use then to completely supplant the "real world" simply leaves you at their mercy and they become a crutch that hinders you rather than helps you.
Ernesto Arroyo wrote:
You throw the exception, but you have to catch it in your main ( or before )
No you don't. You can just let the program die. In particular, since this is an unchecked exception indicating a bug, letting the program die before any further damage is done might be the best course. (Typically, though, RuntimeException and its descendants are caught at a high level).
and print a message (system.out or log4j better, but log4j maybe is a little more advanced now if you are learning)
Simply printing a message is not good exception handling. If the program is to continue running, then the exception actually has to be handled. That is, we have to try again, or we have to provide some alternate execution that serves the same purpose as whatever it was that failed, or or program has to be able to function without that step.
So use a try-catch in the main and in the catch print the message you want.
Don't just print the message. Print the stack trace. And if you're just going to catch it in main, print the stack trace, and exit, then there's no point in catching it at all, as that's what will happen anyway.