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?
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
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)
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.
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.
Cheers, Roberto Perillo
SCJP, SCWCD, SCJD, SCBCD
posted 7 years ago
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
posted 7 years ago
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...
If you're gonna buy things, buy this thing and I get a fat kickback:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database