• 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

Logging / Swallowing exceptions

 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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...
 
Yeast devil! Back to the oven that baked you! And take this tiny ad too:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic