• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Returning in methods with Try catch block

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi!

I have a noobie problem regarding return statements within methods, and I'd really appreciate any kind of help.

So I have a method containing try and catch block (as required) and much like when you have an if else statement...

... I noted you have to return an object for both the try and catch blocks.

Now in my case my method should return a List object.

The way I have tried to overcome this:

- I've initialised a List object to null as an attribute of the class I'm working in.
- Therefore in the catch block would just simply return the null List object, where as the try block would return the non-empty List (which is what I want).
- I then just test to see if the List != null, when the method is invoked... and that is that.

However the method always seems to return null (when it shouldn't).

I would really appreciate any suggestions on alternative (and better) ways to overcome this problem.

I hope that all made sense Thanks in advance.
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It would help if you posted your code. Please UseCodeTags (←click the link to see how)
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tody Dimon wrote:
So I have a method containing try and catch block (as required) and ...


Why "required"?
 
Bartender
Posts: 1845
10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just in terms of best practices, When dealing with lists, I tend to avoid returning null, preferring to return an empty list instead.

In what circumstances will this exception be thrown? Does it make sense to throw an exception from your method to inform the caller that there was an issue?
 
Tody Dimon
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:It would help if you posted your code. Please UseCodeTags (←click the link to see how)



Oh my bad! Here are the two methods I'm working with and the has been initialised as an attribute of the MainActivity class.

I'm working on an android app.



Bear Bibeault wrote:

Tody Dimon wrote:
So I have a method containing try and catch block (as required) and ...


Why "required"?



Thanks for the replies!

I had to catch an exception, otherwise my code wouldn't work

would be highlighted as throwing a twitter4J exception!

Also I am certain the code in the try block works as I've printed out the statuses within the try block that is obtained via the List assignment above (statuses) and they do appear.

I need to do a lot lot more with statuses so I thought it would be better to start a new method.

In the Log cat I keep getting “ did not work!”, which suggests it seems to be returning a null list.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Because you are not handling the exception in any way, you should not be catching the exception on your method.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

on Line 25 27, you declare the variable as allStatuses but on line 29, your condition checks statuses. You and the computer are not on the same page

If I were to code this, I would prefer this structure. As previously suggested, it's better to return an empty list. Also note that there is only one return statement at the end, none inside the try-catch.

Line 4 replaces the details of getting an instance of Twitter with a method call. This helps the reader concentrate on what's really happening in this method. All that code you had there before would go in the getTwitter() method.

Line 6 should be changed to catch the exact exception thrown by the Twitter method. It's poor practice to just catch Exception if there's a more specific exception that can be declared.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Bear has a good point about handling or just letting the exception bubble up. If you want a better user experience, you should probably catch this somewhere up the call stack and at least display a user-friendly message.
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The bug also reveals another design smell: why do you have another statuses reference floating around where it can be accessed by multiple methods? Since you have a getStatuses() method, then you should just use that and if the returned list needs to be accessed by multiple methods, then pass it around as a parameter; don't make it an instance or class variable if you don't really need to. If anything, an instance variable would be named mostRecentStatuses or cachedStatuses or something like that to free up the name statuses for use as a local variable and/or formal parameter.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic