Bug 116818

Will try to do something about this for NB6.0.

No time, sorry.

We'll try to solve it somehow for 6.1.

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.

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.

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).

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.

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.

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.

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.

http://hg.netbeans.org/main?cmd=changeset;node=4090aab6d24c

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. 

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.

Satafen:  Notice that this bug depends on an umbrella bug, issue 124617 - "Allow per-project templating of exception handling (and similar generated) 
code".  

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.

Much appreciated. Hopefully with Jan's fix we can find a way to make 6.0 work for us.

*** Issue 126749 has been marked as a duplicate of this issue. ***

*** Issue 155087 has been marked as a duplicate of this issue. ***

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.

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.

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.