This week's book giveaway is in the Cloud/Virtualization forum.
We're giving away four copies of Learning OpenStack Networking: Build a solid foundation in virtual networking technologies for OpenStack-based clouds and have James Denton on-line!
See this thread for details.
Win a copy of Learning OpenStack Networking: Build a solid foundation in virtual networking technologies for OpenStack-based clouds this week in the Cloud/Virtualization forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

Logging / Swallowing exceptions  RSS feed

 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

I know it doesnt say anything about logging, but I am wondering what you guys did in place of Exception Handling where an error wasnt usable
in terms of response to the client. Did you just eat it and leave a comment?


"Server"


That exception is pretty much swallowed whole.... Gah... hate doing it, needs to be logged, but I am going to remove all my logging at the end... I think others have done that correct? I am using java.util.Logger
 
Sheriff
Posts: 11338
177
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I used logging in the most important classes of my application (data class and business service implementations). I left the logging code in the code when I submitted, but disabled everything. I documented the decision that this code could be re-used for debugging purposes when changing/extending the application.

But when in my code I need to check if the record is still available, I have to do a read after a lock. The read throws a RNFE which I have to catch, but it will never happen, so I decided to just add a code comment (and not log it or do anything else, because if I implemented every method flawlessly the exception will never be eaten, because it never occurs)
 
S. Thakker
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yea, I have alot of those scenarios where flwlessly some of these exception will not be thrown... Many of them I have removed in an effort to get rid of the handling.

For example: Using a MaskFormatter -- I started with this class, but found it too problematic... it was kind of clunky, so I switched to
a custom extension of the Document class which filtered either numbers and or numbers and size. I also went that way because there was an exception, ParseException which must be caught, but since the mask is a constant, there really should be no reason why it should fail, so what would I tell the user.. I needed to System.exit() because it removes a basic restriction.

I get your point, and maybe I would leave some logging in for that purpose... But I just dont want to have to provide a dialog for the location of the log etc... I wil just store it in the current directory.

Thanks for the info.
 
Roel De Nijs
Sheriff
Posts: 11338
177
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just log to the console, so no file is needed

I used a DocumentFilter to have the needed control about user input.
 
Bartender
Posts: 2292
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I didn't use logging at all however, in real life, we have to.

It isn't good to swallow exceptions, because that can lead to subtle bugs, hard to find. If the exception is related to the API (i.e. you have to set a field before calling a method), you can always throw a RuntimeException or one of its subclasses (i.e. IllegalStateException). You can also throw RuntimeException when the interface you have to implement does not include proper exceptions, which is the case of the Data class. When you can create and use an interface, you can use exceptions that extend Exception and use them to represent business failures.
 
S. Thakker
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Robert,

what would you do in a scenario like mine? In the absence of logging.....

You have two choices, pass the error back to the user.... In which this case you may not be able to access the stream or you exit... but you would not want to exit for something like a network glitch... You have to swallow it... Normally it would be a log which you can find it... So I guess we are talking in the real world? In this world, OK to swallow and maybe just throw a IllegalState
 
S. Thakker
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I ended up doing is throwing some runtime exceptions and just not doing anything with them.. but atleast they will be registered on console.

I am a little lost without the logging to tell you the truth. I like the console personally to see what is going on... Since I am wrapping up and now documenting, I am trying to clean up alot of the scenarios where the server is down, database is gone, etc... So much documenting left to do, and I thought I had done alot of documenting while I was doing the coding. Apparently not...
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!