Henry Wong

Sameer Kan wrote:For instance, if someone were to enter a double, string, or boolean input into the scanner instead of an integer, how could I throw an exception for this? I have to do this for an assignment, and they specifically said that I need to use a throw exception for this. Thanks everyone in advance!

The Scanner class nextInt() method will throw an InputMismatchException exception, if the token is not an integer. So, you can catch the InputMismatchException instance and throw an IllegalArgumentException upon catching in the catch block.

Now, having said that, if this is a homework assignment, then I don't think your instructor wants you to use the nextInt() method. Instead, your instructor is probably expecting you to use the next() method instead. This method returns a raw token (string), which you can parse out the integer (or throw the exception).

Henry

Piet Souris wrote:You lucky ... so far I've never won. :

Congratulations!   

Agreed. Congrats to the OP....

I too, have never won a book promotion for the many years that I have been on the ranch. At a certain point, I just considered it destiny, and joined the book promotion staff -- where I no longer am eligible to win...

Henry

Welcome to the ranch Toby. And apologies for the somewhat late start.

Henry

This week, we're delighted to have Toby Weston helping to answer questions about the new book Scala for Java Developers: A Practical Primer. 

The promotion starts Tuesday, June 12th, 2018 and will end on Friday, June 15th, 2018.

We'll be selecting four random posters in this forum to win a free copy of the book provided by the publisher, Apress.


Image from unknown

Please see the Book Promotion page to ensure your best chances at winning!

Posts in this welcome thread are not eligible for the drawing, and should be reserved for welcoming the author. Questions posted in this topic are subject to removal.

Apologies. I will fix that now.

Henry

This week, we're delighted to have J.D. Isaacks helping to answer questions about the new book Get Programming with JavaScript Next: New features of ECMAScript 2015, 2016, and beyond. 

The promotion starts Tuesday, June 12th, 2018 and will end on Friday, June 15th, 2018.

We'll be selecting four random posters in this forum to win a free copy of the book provided by the publisher, Manning Publications.


Image from unknown

Please see the Book Promotion page to ensure your best chances at winning!

Posts in this welcome thread are not eligible for the drawing, and should be reserved for welcoming the author. Questions posted in this topic are subject to removal.

Campbell Ritchie wrote: I am not certain, but because Exception has subtypes which are unchecked, it is regarded as a caatch‑all which might be thrown from the try. Remember the javac tool doesn't actually check whether an unchecked exception is thrown or not, so for all it knows when it reaches the catch(), maybe an unchecked Exception has been thrown.

Yes. It is because Exception instances includes unchecked exceptions.

Arpan Ghoshal wrote:
I have left the try block empty then how is there a potential for a Exception. Can someone explain which exceptions have a potential to be thrown even if I leave the try block empty ?

I don't think it matters if an exception will be thrown at runtime or not. For unchecked exceptions, it is ... well ... unchecked. If the environment is not going to check if something will be thrown or not, how can you confirm that something will or won't be thrown?

Henry

Arun Kriss wrote:
I found this forum is not providing the solution rather coming with problem statement.

The ranch is a teaching site. We will help you with learning the techniques, and even the best practices, to get to the solution yourself. In order to do that we need to know what you are having trouble with.

If you just want the solution, and have it provided with a required service level, there are consulting companies that do that. Of course, the higher the service level, the likely higher cost.

Henry

Does the program / classes compile?

Henry

Welcome to the ranch !!

Henry

Jake Monhan wrote:
Although the code on page 193 is about overloading, looking at the that code and your sample, I wonder if I missing fundamental concept of how a method with return of void vs. a method having return, is handled.

Method overloading does not take into account the return type, in order to disambiguate the method; so, I am not exactly sure what concept you seem to be missing.

As for the void return type, method that return void can only be used in Java statements, while methods that return a value can be used in Java statements and/or expressions.  Of course, I may have caused more confusion, as you probably haven't learned the subtle difference between a statement and an expression yet....

Henry

Red Nano wrote:
New client from: 192.168.1.56
Message Received: 1002
Socket Closed
New client from: 192.168.1.56
Message Received: 1003
Socket Closed
New client from: 192.168.1.56
Message Received: 1005 <- Message 1004 skipped, but confirmed read by the client on the hardware itself (green light and confirmation beep)
Socket Closed

If I have to speculate, you have a race condition. The client sends message 1003. While your server is processing message 1003, the client sends message 1004. When your server tears down the socket, it will take message 1004 with it. The client then re-connects and sends message 1005.

Henry

Red Nano wrote:
Before sending any data, I see the client connecting, so I assume it establishes a connection before sending data.
After the server disconnects, the client seems to connect again, even if there's still no message to send.
Thus I can assume the client always tries to keep an open connection, while my server closes every time a message is received.

Yeah, don't do that. If the sender wants an always up connection, then don't disconnect. Constantly disconnecting (and forcing a re-connection) is very expensive !!

Henry

Andrzej Zahorski wrote:My current concept about it is: I use interface in generics to ensure that type I will use  implements it, so if I put something that not overrides it, I'll get an error.

Correct. If you try to call it with a type that doesn't implement Comparable, the compiler will not match it to that method. And if there are no other overloaded methods that can match, then you will get a compiler error.

Henry