- having user-private files under version control is a really bad idea (private/private.properties). You would be much happier with leaving it out of VCS
- not sure if netbeans.exception.report.min.level makes any sense here. You're probably not getting any exception but a warning dialog i guess.
passing to projects, do you try locking the private.properties file?

can you attach a screenshot of the dialog?

in general I agree with ovrabec, private.properties should not be part of the version control. On top of that it should be readable. Not complying with that constraints can cause errors/sideeffects in the IDE and that's why we report it. 

netbeans.exception.report.min.level is unrelated to generic warning dialogs and only applies to logged messages in relation with the exception reporter (can be thought of as property/API of the exception reporter)

and what project type are we talking about? j2se/web/...?

(In reply to Ondrej Vrabec from comment #1)
> - having user-private files under version control is a really bad idea
> (private/private.properties). You would be much happier with leaving it out
> of VCS
> - not sure if netbeans.exception.report.min.level makes any sense here.
> You're probably not getting any exception but a warning dialog i guess.
> passing to projects, do you try locking the private.properties file?

The same problem occurs if any of the files in nbproject are locked not just private.properties. 
We would be much happier leaving it out of VCS yes except that netbeans automatically updates it to point to a user's personal netbeans properties file; if using netbeans project supplied ant build (build-impl.xml), then the build automatically uses the dependencies listed in the user's personal netbeans properties file over the ones listed in project.properties.

Regardless of whether having the private.properties is bad idea the exception reporting behavior and dialogs should behave consistently throughout netbeans and in this case they do not.  

(In reply to Milos Kleint from comment #2)
> can you attach a screenshot of the dialog?
> 
> in general I agree with ovrabec, private.properties should not be part of
> the version control. On top of that it should be readable. Not complying
> with that constraints can cause errors/sideeffects in the IDE and that's why
> we report it. 
> 
> netbeans.exception.report.min.level is unrelated to generic warning dialogs
> and only applies to logged messages in relation with the exception reporter
> (can be thought of as property/API of the exception reporter)

The problem with this statement is that setting netbeans.exception.alert.min.level=9999 does disable the dialog from appearing.  According to the API documentation this should not be the case.  This error does gets logged in the log so based on what you are saying the netbeans.exception.report.min.level should affect it.


(In reply to Milos Kleint from comment #3)
> and what project type are we talking about? j2se/web/...?

The same problem occurs for j2se/web/ear etc.

(In reply to bdrx from comment #4)
> (In reply to Ondrej Vrabec from comment #1)
> > - having user-private files under version control is a really bad idea
> > (private/private.properties). You would be much happier with leaving it out
> > of VCS
> > - not sure if netbeans.exception.report.min.level makes any sense here.
> > You're probably not getting any exception but a warning dialog i guess.
> > passing to projects, do you try locking the private.properties file?
> 
> The same problem occurs if any of the files in nbproject are locked not just
> private.properties. 
> We would be much happier leaving it out of VCS yes except that netbeans
> automatically updates it to point to a user's personal netbeans properties
> file; if using netbeans project supplied ant build (build-impl.xml), then
> the build automatically uses the dependencies listed in the user's personal
> netbeans properties file over the ones listed in project.properties.


and that's correct this way. If you want to have shareable dependencies/libraries, you should have used the mechanics that is actually supported by the IDE. Eg. project wizard has "use dedicated folder for storing libraries". For existing projects the location of library storage area can be changed in Libraries panel in the project customizer. Then libraries become part of the source code or any other setup.

https://netbeans.org/kb/docs/java/project-setup.html#projects-shared-libraries
https://blogs.oracle.com/tm/entry/project_with_sharable_libraries_aka


> 
> (In reply to Milos Kleint from comment #2)
> > can you attach a screenshot of the dialog?

Can you attach a screenshot of the dialog?


> > 
> > in general I agree with ovrabec, private.properties should not be part of
> > the version control. On top of that it should be readable. Not complying
> > with that constraints can cause errors/sideeffects in the IDE and that's why
> > we report it. 
> > 
> > netbeans.exception.report.min.level is unrelated to generic warning dialogs
> > and only applies to logged messages in relation with the exception reporter
> > (can be thought of as property/API of the exception reporter)
> 
> The problem with this statement is that setting
> netbeans.exception.alert.min.level=9999 does disable the dialog from
> appearing.  According to the API documentation this should not be the case. 
> This error does gets logged in the log so based on what you are saying the
> netbeans.exception.report.min.level should affect it.

If you had attached the picture of the dialog you speak about, things would be a bit clearer by now.  What do you mean by "The problem with this statement is that setting netbeans.exception.alert.min.level=9999 does disable the dialog from appearing." A typo? it appears to contradict your claims from the initial comment.

please note that the netbeans.exception.report.min.level only affects handling errors/exceptions that are not caught by domain specific code. If the thrown exception bubbles up to the exception reporter, it will decide if a dialog is shown or not. In dev builds it's a popup dialog, in final releases just a bubble in status bar BTW. 
BUT the property has no influence on 
1. logging to the messages.log file done by domain specific code.
2. any dialogs that are shown by domain specific code when handling exceptions.
3. also unlikely to influence if the exception reporter logs the exception to messages.log.


> 
> 
> (In reply to Milos Kleint from comment #3)
> > and what project type are we talking about? j2se/web/...?
> 
> The same problem occurs for j2se/web/ear etc.

the dialog comes from this code in OpenProjectList.java (on project close)
   

ErrorManager.getDefault().notify(ErrorManager.INFORMATIONAL, e);


and from ProjectHooks.java on project open via

Exceptions.printStackTrace(e);

both are fairly common means of reporting problems to the user.

> > The problem with this statement is that setting
> > netbeans.exception.alert.min.level=9999 does disable the dialog from
> > appearing.  According to the API documentation this should not be the case. 
> > This error does gets logged in the log so based on what you are saying the
> > netbeans.exception.report.min.level should affect it.
> 
> If you had attached the picture of the dialog you speak about, things would
> be a bit clearer by now.  What do you mean by "The problem with this
> statement is that setting netbeans.exception.alert.min.level=9999 does
> disable the dialog from appearing." A typo? it appears to contradict your
> claims from the initial comment.
> 

I have attached a screen shot; it can easily be reproduced though by making any build/project file in the nbproject directory read only.

It is not a typo and does not contradict the initial comment. There are 2 different netbeans properties for specifying exception level: netbeans.exception.report.min.level and netbeans.exception.alert.min.level.

From the documentation found at http://bits.netbeans.org/dev/javadoc/properties.html:

netbeans.exception.alert.min.level in Bootstrap

   Minimum integer level that triggers the blinking icon signaling an exceptional state. By default 900 - e.g. WARNING.

netbeans.exception.report.min.level in Bootstrap

   Minimum integer level that triggers the dialog with exception. By default 900 with assertions on and 1001 without them.

Created attachment 143731 [details]
netbeans cannot lock read-only file dialog

As you can see in the screenshot the problem does not just occur with private.properties but also project.properties.  
Whether or not private.properties should be made read-only is independent of the problem reported.  The problem is that the netbeans.exception.report.min.level property is not behaving as documented and the netbeans behavior should be consistent for the different error dialogs.

As a side note, when depending on the netbeans ant build xml files for building an application, having the build change and break because the project was opened in netbeans for viewing and netbeans automatically modified the build_impl.xml or project.properties is less than ideal behavior. This can easily happen if the project was created with an older version of netbeans and a user opens the project for viewing in a newer version of netbeans.  The work-around/solution to this problem is to either not use netbeans files for building or to make the ant build files read-only.

(In reply to bdrx from comment #9)
> Whether or not private.properties should be made read-only is independent of
> the problem reported.  The problem is that the
> netbeans.exception.report.min.level property is not behaving as documented
> and the netbeans behavior should be consistent for the different error
> dialogs.

no, as I explained above netbeans.exception.report.min.level property is unrelated to the dialog popup you are seeing.

> 
> As a side note, when depending on the netbeans ant build xml files for
> building an application, having the build change and break because the
> project was opened in netbeans for viewing and netbeans automatically
> modified the build_impl.xml or project.properties is less than ideal
> behavior. This can easily happen if the project was created with an older
> version of netbeans and a user opens the project for viewing in a newer
> version of netbeans.  The work-around/solution to this problem is to either
> not use netbeans files for building or to make the ant build files read-only.

Unfortunately that's how the entire thing is designed to work. Fighting it the way you do is counter productive as far as I can see. There are ways (like the shared libraries I mentioned above that are meant to make projects more easily shareable across developers. 
Alternatively you would be better off switching to free form ant projects, maven projects or different IDE.

This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue.

Thanks for your cooperation,
NetBeans IDE 8.2 Release Boss