Issue 4019: GCPR issue: Exceptions                                                                                                                                                                                  (coas-ftf)
Source:  (, )
Nature: Enhancement
Severity: 
Summary: In the current specification we find that exceptions are limited.  For example, when invoking get_observations_by_time, the patient specified may not exist on the server.  We can return empty ObservationData in this case, but a more descriptive exception such as "patient not found" would be useful here. Other exceptions that give information for "no results found" or "unable to get access" or "system down" etc. would give the client more flexibility to notify the user of the status of the call and how to handle any repeated tries.  In other words, more application level information should be allowed to be sent back. These types of enhancements will require input from programmers and developers to make sure we capture relevant and meaningful exceptions.
Resolution: see above, issue rejected
Revised Text: 
Actions taken:
November 6, 2000: received issue
February 27, 2001: closed issue
Discussion: 
exception InvalidCodes {
QualifiedCodeStrSeq codes;
};

exception InvalidIds {
ObservedSubjectIdSeq ids;
};

ObservationDataSeq get_observations_by_time (
in ObservedSubjectId who,
in QualifiedCodeStrSeq what,
in TimeSpan when,
in unsigned long max_sequence,
out ObservationDataIterator the_rest )
raises (
InvalidIds,
InvalidCodes,
DuplicateCodes,
InvalidTimeSpan );

For an exception like "patient not found" get_observations_by_time uses the InvalidIds exception to notify the user that there is a problem with the ObservedSubjectId that was passed in.  
Passing back an empty "any" indicates, "no results found"
An exception for "unable to get access" could be interpreted as a security problem and should be handled through a security mechanism. 
An exception for "system down" can be handled when the client attempts to get a handle to the server.
When the submitters were working on this specification exceptions were of concern as to how in depth we should go. There were multitudes of possibilities that the submitters felt were to extension to list and based on the usage could be very extensive.
What was discussed and remains today, is that; what is really needed is a robust Error Handling Facility that could be used to catalog and provide textual messages for clients to display to their users providing run-time and administrative capabilities that all submissions could use. This would provide a more extensible solution to the never-ending possibilities of exceptions. This, of course, is out of scope for this submission.
The submitters encourage those who have a burning desire to pursue the topic of error handling to bring solutions forward to the OMG and see where such a facility may fit in. 

End of Annotations:=====
Exceptions
In the current specification we find that exceptions are limited.  For
example, when invoking get_observations_by_time, the patient specified
may not exist on the server.  We can return empty ObservationData in
this case, but a more descriptive exception such as "patient not
found" would be useful here. Other exceptions that give information
for "no results found" or "unable to get access" or "system down"
etc. would give the client more flexibility to notify the user of the
status of the call and how to handle any repeated tries.  In other
words, more application level information should be allowed to be sent
back. These types of enhancements will require input from programmers
and developers to make sure we capture relevant and meaningful
exceptions.