MantisBT - JANA
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000191JANABugpublic2012-01-30 08:172012-03-27 10:21
Reporterdavidl 
Assigned Todavidl 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Summary0000191: behavior when gPARMS is missing
DescriptionThis from an email sent by Mauri on 1/3/2012:

---------
Just FYI, if jana doesn't find a gPARMS parameter, it will throw an exception with this message:

JANA >>Launching threads .
JANA >> Factory Call Stack
JANA >>============================
JANA >> BSTnoise
JANA >> JEventLoop:OneEvent -- line:495 JEventLoop.cc
JANA >>----------------------------
JApplication.cc:963 EXCEPTION caught for thread 0xb0207000 : std::exception


I think it would be better to have an explicit msg stating that the parameter is missing?

mauri
---------
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2012-01-30 08:17davidlNew Issue
2012-02-02 08:05davidlNote Added: 0000299
2012-02-02 08:05davidlStatusnew => assigned
2012-02-02 08:05davidlAssigned To => davidl
2012-02-02 08:35davidlNote Added: 0000300
2012-02-06 14:19davidlNote Added: 0000303
2012-03-27 10:21davidlNote Added: 0000326
2012-03-27 10:21davidlStatusassigned => resolved
2012-03-27 10:21davidlResolutionopen => fixed

Notes
(0000299)
davidl   
2012-02-02 08:05   
I believe this is occurs because the user is not catching the exception and it falls to the catch-rethrow mechanism built into JANA whenever JEventLoop::Get is called. The original exception is thrown from:
 
JParameterManager::GetParameter(K key)

Whether a parameter not being present warrants an exception, an error message, or and error code is a design choice. I still believe the exception is the right way to go. However, this should be addressed with a configuration parameter to allow the user to change the behavior if they prefer a different choice.
(0000300)
davidl   
2012-02-02 08:35   
It turns out the exception mechanism inside GetParameter cannot be simply turned off since it is an integral part of the flow control for SetDefaultParameter. I have sent an e-mail to Mauri asking for clarification and proposing a GetParameterNE method (NE=No Exception) that would wrap the existing GetParameter method, but print an error rather than throw an exception.
(0000303)
davidl   
2012-02-06 14:19   
The real issue here is that no message indicating that GetParameter was called specifying a non-existant parameter caused the crash. It appears that such a message is included in the exception thrown from GetParameter, but somehow did not make it to the screen in Mauri's error message (see original description).
(0000326)
davidl   
2012-03-27 10:21   
This was fixed in revision 941 and will appear in JANA 0.6.4.

The message sent with the exception is now printed first to guarantee the user sees it.