Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 116818 - surround with ... inserts wrong logging code
surround with ... inserts wrong logging code
Status: NEW
Product: java
Classification: Unclassified
Component: Editor
All All
: P3 with 8 votes (vote)
: 6.x
Assigned To: Dusan Balek
: 126749 155087 (view as bug list)
Depends on: 124617
  Show dependency treegraph
Reported: 2007-09-26 13:37 UTC by tkellerer
Modified: 2013-09-05 14:17 UTC (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description tkellerer 2007-09-26 13:37:29 UTC
We are not using the Java Logging API or Log4j in our project, and thus the code that gets inserted with "Surround with
try catch" is not valid for my project. I cannot find a way to customize the (logging) code that is put into the catch
block and thus have do delete the code each time I use this feature. Actually it's quicker to code the try catch
manually than to remove the incorrect code.
Comment 1 Jan Lahoda 2007-10-03 21:36:37 UTC
Will try to do something about this for NB6.0.
Comment 2 Jan Lahoda 2007-10-30 15:26:02 UTC
No time, sorry.
Comment 3 Jan Becicka 2007-12-13 21:37:29 UTC
We'll try to solve it somehow for 6.1.
Comment 4 santafen 2007-12-13 21:58:55 UTC
This is a show-stopper for me. I am unable to use NB6.0 because this is such a huge hit to productivity. Will stick with 5.5 until this is fixed.
Comment 5 _ tboudreau 2007-12-14 15:04:14 UTC
I know we generate different code if you're developing a NetBeans module;  it seems to me that there should be some way of specifying the template used for 
what to do in a catch block in the project metadata - in most cases a given project will have a standard way of handling caught exceptions, and this is likely 
to vary widely.
Comment 6 santafen 2007-12-14 15:08:52 UTC
That would be ideal Tim. Anything that lets the developer decide what the code that gets inserted is would be preferable.  Most development shops will have 
"standards and practices" around what these code blocks should be. Allowing them to be configured to conform to their own standards would be a huge win.

Barring that, the *simplest* (printStackTrace()) is preferred over the highly complex (Logger).
Comment 7 _ tboudreau 2007-12-14 23:58:48 UTC
Disagree about reverting to printStackTrace() - in any project of even trivial complexity, there may be some official thing you're supposed to do with 
exceptions, but it surely will not be printStackTrace().  Using Logger at least has a higher probability of being right than printStackTrace().  And for immature 
projects, it encourages handling this sort of thing sanely.
Comment 8 santafen 2008-01-02 19:37:26 UTC
Sorry to disagree again, but having the NetBeans team decide what is appropriate (REQUIRED!) for me is not acceptable.

If the surround-with code is not configurable, it should be least-common-denominator. printStackTrace(). Requiring the Log4j stuff is simply wrong. It won't 
fly with JavaME development, for sure.

Comment 9 ericarseneau 2008-01-02 19:43:01 UTC
Regardless of opinions on how exceptions should be handled, this is not up to us to decide completely.

I think we are losing site here of the fact that it should be configurable.  All code templates that we use must be configurable at the IDE and project level.  At 
the moment, the way try..catch is inserted, it is of no use to me as I have to go and delete the code it inserts.  This would remove the issue of what should be 
placed inside the catch block by allowing users to specify what they want, and we provide what we think they should want.

This should be a general principal, any code we insert, should be templatable and configurable by the user at both the IDE and project level.
Comment 10 Jan Lahoda 2008-02-04 19:21:38 UTC
I have integrated a partial fix (id: 4090aab6d24c), which allows to select which logger statement to use - see
Tools/Options/Java Code/Hints/Error Fixes. It is not a perfect solution, but I do not think we can get anything
significantly better for 6.1. A text field where a custom logging statement could be specified would be nice, but I am
not sure if there will be enough time to do it for 6.1.;node=4090aab6d24c
Comment 11 santafen 2008-02-04 22:02:46 UTC
sadly, this is hardly a fix. Apparently I wasn't clear enough in the original bug report: Using Logger is unacceptable. 

Is that clear enough? An *OPTION* to use Logger would be ok, but a way to opt OUT of using Logger is required. 
Comment 12 Jan Lahoda 2008-02-04 22:28:44 UTC
Well, "logger statement" means "statement to log (exception)" - the partial fix allows user to select use of
java.util.logging.Logger, Exception.printStackTrace or org.openide.util.Exceptions.printStackTrace - so there is a way
to opt-out from using Logger.
Comment 13 _ tboudreau 2008-02-04 22:46:49 UTC
Satafen:  Notice that this bug depends on an umbrella bug, issue 124617 - "Allow per-project templating of exception handling (and similar generated) 

I'm sure when that bug is fixed, it will solve the problem the way you want it solved.  In the meantime, Jan is trying to help you by providing an imperfect but 
workable solution that does eliminate Logger usage.
Comment 14 santafen 2008-02-04 22:50:09 UTC
Much appreciated. Hopefully with Jan's fix we can find a way to make 6.0 work for us.
Comment 15 Vince Kraemer 2008-02-06 17:26:33 UTC
*** Issue 126749 has been marked as a duplicate of this issue. ***
Comment 16 Jan Lahoda 2008-12-10 10:50:32 UTC
*** Issue 155087 has been marked as a duplicate of this issue. ***
Comment 17 _ wadechandler 2008-12-10 14:38:07 UTC
From my issue closed as a duplicate...this came up on nbusers, and folks want it:

Surround with try-catch should allow a user to enter a template just like in code templates which can be used to setup
their catch statements to match whatever libraries they may be using. A user on nbusers brought this up, and they would
wish to use LogFactory. Too, it is possible some others would want to use other APIs. This sounded like a good idea, so
I filed an issue for them (one of the duplicates).

I believe the current options should still be available as check boxes such as:

_ Use o.o.u.Exceptions.printStrackTrace
_ Use j.u.l.Logger
_ Use Exception.printStackTrace (though this one needs to really be able to be turned off...isn't able now)
_ Use custom template

and that would fix the issue. The third option needs to be able to be turned off. We should never FORCE anything upon
someone when it does need to be. A better default when nothing is checked is to do nothing. Sometimes folks want that.
Comment 18 _ tboudreau 2008-12-11 01:48:45 UTC
Given that we now include formatting settings on a per-project basis, it seems like a logical extension of it to allow
for per-language templating of things like how to handle exceptions.  

There is never going to be a one-size-fits all answer for what to do in this sort of situation.
Comment 19 _ rkubacki 2013-09-05 14:17:34 UTC
It would be nice to add an option to generate SLF4J logging code here. It seems to be a favorite library recently . It is nice because you can choose one logging library and send other to it through this facade which is nice once you build non-trivial app with varying dependencies dragging all possible styles of logging. And then you will likely use it for your code as well thus the request to get help from tools.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo