Wicket - Proper clean up of Page components after exception handling

Question

In my wicket application, Page navigation is by creating new Page object by calling the constructor of the new Page on the onClick() methods. As below.

DisplayItem.add(new Link("edit") { 
@Override
   public void onClick() {
    try{
    setResponsePage(new ReportPage(object, getPageReference()));
       } catch ( CustomException e){
          /// set some feedback message
        }
   }
});

ReportPage has several LoadableDetachableModels, PageableListViews, Panels, Fragments etc. I am doing exception handling in the constructor of the ReportPage and throws it back if an exception occurs. Ses below. ( partial code )

 public ReportPage(final Objectm, final PageReference pr) throws CustomException{

try{
final LoadableDetachableModel<MaintReport> ldm = 
         new LoadableDetachableModel<MaintReport>() {

            @Override
            protected MaintReport load() {
                return new MaintReport();
            }
        };

/*

Several LoadableDetachableModels, PageableListViews, Panels, Fragments  etc.

*/ 


} catch ( Exception ex){
// create Custom Exception 

} finally {

 // Clean up of stuff 

}

So if an exception occurs in constructing the page. How should I do clean up ( in the finally block ) ? . Should I set all the individual objects to null ? Is there any Wicket method to garbage collect ( or send signal to GC) ?

Thank you

Apart from the merit of your question why not handle the exception login in the ReportPage as this page knows what went wrong and how to deal with it? This way you are having logic about on Page in two or more places ... — Robert Niestroj, Feb 15 '13 at 13:38
Am I missing something or shouldn't the garbage collector take care of situations like this? — Nicktar, Feb 15 '13 at 13:40
@RobertNiestroj I am having a seperate try..catch block in report page and am logging the error, but if I don't throw a Exception, wicket will generate a Runtime page exception as the components marked in the html pages are not rendered. I think , I will amend my post to add more clarity. — Jay, Feb 15 '13 at 13:46
@Nicktar By defaut it does, but isn't it a good practice to set the newly allocated objects to null for the garbage collector to perform deallocation ? — Jay, Feb 15 '13 at 13:53
@jkcool Not anymore. In the very early versions of java this was recommended. I don't know when this changed but any version that was published during this decade doesn't need this anymore. The gc can find unreferenced objects without requiring them to be set tu null. — Nicktar, Feb 15 '13 at 14:01

score 1 · Accepted Answer · answered Feb 17 '13 at 18:15

Throwing an exception form within a constructor immediately makes the half initialized object eligible for garbage collection. Unless you are somehow preventing it by say adding the object into a collection owned by another object before the exception was thrown, there is no need to worry about the deallocation of this object and its fields. You still need to release any unmanaged resources that may have already been allocated (e.g. file handles) as you would normally do in your finally block.

I guess, I get the point now. Anyways, my application does not have file handles, my db connection is managed at server level by a connection pool and DB operations are managed by entity beans. — Jay, Feb 18 '13 at 09:16

Wicket - Proper clean up of Page components after exception handling

1 Answers1