This should be addressed in the latest pre-release. I completely overhauled the exception handling, which took way longer than I wanted it to, but I felt like it needed to be done. I also fixed a ton of formatting issues with the code and attempted to make it at least consistent with itself and more or less compliant with the Java code conventions (at least the ones I agree with.)
The exception handling now works similarly to that of the Windows viewer. There are three basic types of exceptions: WarningExceptions indicate failures that are generally expected as a result of either a user action or some other normal condition, ErrorExceptions indicate failures that are generally unexpected but have known causes, and SystemExceptions originate as exceptions in lower-level Java methods and indicate failures whose causes are generally not known. Examples of WarningExceptions are authentication failures, entering the wrong hostname, trying to connect to a display that has no VNC server running on it, losing the connection due to a network hiccup or the server being shut down, etc. WarningExceptions display a user-friendly message with a yellow caution symbol instead of the red stop sign, and they don't say "error", even though they still result in the viewer exiting. ErrorExceptions also display a user-friendly message, but it has the traditional red stop sign and says "Error". SystemExceptions display the traditional unfriendly text that contains information about the exception class. Stack traces are only printed out for SystemExceptions, since, unlike the other types of exceptions, the origin of SystemExceptions won't be obvious from the exception text. Hopefully that will get you where you need to go. Overhauling the exception framework lays the groundwork for possible future enhancements, such as a parameter that would allow one to specify that a particular type of exception should not raise a dialog, and we can also now easily convert an exception from one type to another if you discover other error dialogs that you want to be made friendlier. On 12/11/12 3:44 PM, James Wettenhall wrote: > DRC, > > Yes, it would be better if a "Connection Closed" message box was > displayed instead of seeing the EndOfStream exception. And for less > common Java exceptions, I think it's reasonable to display the raw > Java class name in a message dialog. > > For our cloud virtual machines, instead of having the End Session > button seen on our HPC system's desktop (which is triggering the > EndOfStream exception), the user finishes by simply closing the VNC > window. Our application then pops up a question dialog asking whether > the user wants to keep their VNC session open for future use, or > terminate it. So this use case (the user simply closing the VNC window > and exiting TurboVNC) wouldn't trigger any Java message boxes, which > is good for us. > > Cheers, > James ------------------------------------------------------------------------------ LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
