Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"

Heena Agarwal

Ranch Hand
+ Follow
since Dec 25, 2013
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Heena Agarwal

Karthik Shiraly wrote:In fact, I took this course because other ranchers here had good things to say about it. You might find the previous discussion on it quite informative.

For some reason my posts in that thread seem too discouraging. I think it's not too difficult to complete this course with a full time job if that job and your chores give you a healthy lifestyle.

These days you get two weeks to complete the assignment without penalty and almost about a month to complete it with little penalty. That is really a cool thing. To anybody considering to take up this course, I'd say, go for it.
4 years ago

Amar Saikia wrote:This Algo class again started from 13th June. Probable this time we can pick up from where we left. Is anyone else doing this time?

I am not doing the algorithms' course but I have the videos and I did refer to a few of their videos much later. I want to do this course. And I will as soon as I can...
How is the course coming along for you?
5 years ago
Are you ok with paperback quality? If so, I think you can order 'Java SE8 for the really impatient' online from Following is the link.

I have ordered books from flipkart many times and my books have arrived in time and in good condition.

Edit : I know you said hard cover. But I don't know if there's any Java 8 book that is available in hard cover in any part of the world currently. I only see kindle and paperback editions in the following page.
5 years ago

Is it because of '? extends ' instead of '? super' expression, the compiler wont let me add anything to the list.

But it's important to understand why. I suggest you go through the following post also

and try to understand the question and the responses. I think that might give you more clarity.

No idea what you mean by a rock solid singleton, but reflection attack is possible with your implementation.

The output of the above mentioned code is --


5 years ago

Tushar Goel wrote:But i want to know why problem is coming with first option and which one is more elegant to use.

Hi Tushar,

I've been trying to work on your problem for my own learning. Following is what I think is the case.

An uncaught exception handler is not really the same thing as any other catch block. A catch block catches an exception and prevents the thread that threw the exception from terminating if the exception is successfully caught, i.e if the catch block does not result in another exception being thrown. An uncaught exception handler on the other hand is just a facility provided by the Thread class to enable the thread to do additional things before it terminates. Those additional things could be anything - like for example, sending an email to an admin, logging, starting a new Thread -- it really depends on your use case.

In case of worker threads like configurations, the worker thread has no idea of what kind of tasks it is going to run. Some tasks can be nicely coded, but the worker thread has no way of knowing that. So if a worker thread is supposed to execute say 10 tasks, and say task number 5 throws an uncaught RuntimeException, it could terminate the worker thread. This is not what you'd want. This is one of the cases where the uncaught exception handlers come in handy. I could have the uncaught exception handler start another worker thread to execute the remaining tasks. But this wouldn't happen just by implementing the Thread.UncaughtExceptionHandler interface and coding the uncaughtException method to just log the exception. Unlike a catch block, an uncaught exception handler does not prevent the original thread from terminating.

The JLS says the following about the UncaughtExceptionHandlers.

JLS wrote:During the process of throwing an exception, the Java Virtual Machine abruptly completes, one by one, any expressions, statements, method and constructor invocations, initializers, and field initialization expressions that have begun but not completed execution in the current thread. This process continues until a handler is found that indicates that it handles that particular exception by naming the class of the exception or a superclass of the class of the exception (§11.2). If no such handler is found, then the exception may be handled by one of a hierarchy of uncaught exception handlers (§11.3) - thus every effort is made to avoid letting an exception go unhandled.

JLS wrote:If no catch clause that can handle an exception can be found, then the current thread (the thread that encountered the exception) is terminated. Before termination, all finally clauses are executed and the uncaught exception is handled according to the following rules:

If the current thread has an uncaught exception handler set, then that handler is executed.

Otherwise, the method uncaughtException is invoked for the ThreadGroup that is the parent of the current thread. If the ThreadGroup and its parent ThreadGroups do not override uncaughtException, then the default handler's uncaughtException method is invoked.

Let us consider an example. I have a Task class as follows.

Following is my worker thread's implementation. MyRunner is a Runnable that executes tasks in a list within its run method.

If I run the MyRunner class with the commented part as commented, I get the following output.

Thread-0 is running task number 0
Exception in thread "Thread-0" java.lang.RuntimeException: Some stupid RE
at threadandsynchronization.Task.execute(
at Source)

So an exception in the 1st task has terminated my worker and hence tasks 1 till 9 could not run. Obviously if the Task class had a catch-all, my worker thread would not get terminated, but a worker thread does not know if the task is a well planned task. It should prepare for failures in the called code.

Now if I uncomment the UnCaughtExceptionHandler parts, I get the following output.

Thread-0 is running task number 0
Uncaught Exception received. Recieved error on Thread-0 thread. Some stupid RE
Thread-1 is running task number 1
After catch in the task 1
Thread-1is done executing task 1
Thread-1 is running task number 2
After catch in the task 2
Thread-1is done executing task 2
Thread-1 is running task number 3
After catch in the task 3
Thread-1is done executing task 3
Thread-1 is running task number 4
After catch in the task 4
Thread-1is done executing task 4
Thread-1 is running task number 5
Uncaught Exception received. Recieved error on Thread-1 thread. Some stupid RE
Thread-2 is running task number 6
After catch in the task 6
Thread-2is done executing task 6
Thread-2 is running task number 7
After catch in the task 7
Thread-2is done executing task 7
Thread-2 is running task number 8
After catch in the task 8
Thread-2is done executing task 8
Thread-2 is running task number 9
After catch in the task 9
Thread-2is done executing task 9
After all tasks have started

In your first case, you are just logging the exception as a part of the Uncaught exception handler. This will not prevent the thread that is calling the startServer method from terminating.

Obviously you need to analyze why you are getting the StringIndexOutOfBoundException. That is the real problem you need to solve. But to think that an uncaught exception handler that just logs an exception can catch an exception just like a catch block does would be wrong in my opinion.

To answer the question, which of the two things are better, I think that an uncaught exception handler and a catch-all block in the task class are not mutually exclusive. Worker threads execute tasks generally through an abstraction and since tasks are unknown kind of things to worker threads, uncaught exception handlers are good regardless of whether the task has a catch-all block.

I don't know if a catch-all block in the Task class is a good idea. Obviously the catch-all block would make sure the failure condition will not cause the invoking thread to terminate, which is what well planned tasks do. But you don't require a catch-all to catch ( and handle in the correct way ) all the likely failure conditions. Also catch-all's are risky. I mean you never know for how long you are still using the corrupted data till you see a failure later. But that's just one of the things ( significant things ) and it really depends on your implementation and the possibilities with your use case.
5 years ago
[quote]I think it is worth mentioning Martin Odersky scala course at[/quote]

I've heard good reviews of the course. I had enrolled into the course a month back.

They've released the first set of lectures. I might have some time next month, so I'm hoping I'll be able to keep up with the course. I have done the mistake of enrolling into two coursera courses at the same time in the past. Since I'm not going to be repeating that mistake this time, I might as well be able to keep up with the course. :-)
5 years ago
You have 40 audit tables. Purging audit data may take a considerable amount of time. So you might want to have more than a single job that can run in parallel.

Is 15th of every month also the time when the database is not going to be very busy? That might also be a thing to consider.
5 years ago
Yes Jesper, I get what you are saying. His compareTo method isn't consistent with his equals and hashCode methods, which, like you said is the root cause of the problem. :-)

The OP needs to fix that.

5 years ago
Does a TreeSet even use the hashCode and equals methods? I remember my TreeSet implementations would work without them.

I thought a TreeSet only used compareTo/compare method to place objects into the Set.

Edit : But I understand that the contract of compareTo must be kept.
5 years ago

Heena Agarwal wrote:
We all know what the output would be.

Actually, no. We all know what the output could be should be the right thing to say.
5 years ago
Ok, let us create a bad class that doesn't keep the equals and hashCode contract.

Now let us test this MyBadclass...

We all know what the output would be.

Obviously an object has one hashCode. So we can't test why different hashCodes may not imply different objects by just invoking the hashCode method. Let us not know in advance that we have one object only. Let us put this object in a collection and then use hashCode to see if the hashCode alone can tell us if two objects are different.
5 years ago
I am very sensitive to sounds of any kind while I'm working on something that requires concentration. I'm too easily disturbed.

At my first job, we had a gang of co-workers from another team who loved to come for breaks towards our side of cubicles and they loved to talk about movies/fashion/politics/sports and what not too loudly. We had a very grand cafeteria in the 11th floor but they wouldn't go there. Also we had kind of a decently nice walking space in the campus but they wouldn't go there also. They just loved to disturb us. Once we put up a note on the adjacent wall that said - 'people are working in the adjacent, so please keep the volume down'. But that didn't help much. I used to frequently go to an unoccupied conference room and work from there. Thank God, we had those conference rooms.

And I've realized that I end up editing my posts that say things about my current workplace.

5 years ago
Thanks, Winston. Those are really nice examples. Arrays.asList() was an interesting example of an adapter. I did understand the adapting part of an adapter, it's the enhancing the interface part that I was a little confused about.

I thought that the adapter was supposed to enhance the target interface in a way that those enhancements would be independent functions. So I thought that I was supposed to add a new method to say my EnumerationIterator. Granted I can add that method, but I have really not enhanced the Iterator interface this way cause I can't invoke it if all I know is that EnumeratorIterator is an Iterator.

What I mean is I can't do this for example--

But I can have myIt invoke a method that is declared in the Iterator interface, say the remove method and have my implemented version of remove() method invoke myNewMethod().

I know that an adapter adapts an adaptee to a target interface but I am not really sure how an adapter can enhance a target interface. Perhaps by new features the authors meant the same things as having a new implementation of methods declared by the interface and these new implementations can invoke new features. But I'm not too sure about this.

I understand how a decorator adds additional behavior.
5 years ago