D
dbeavon
Guest
I have a repro now, and I'll submit to tech support. Insofar as the openclient exception implementations go, I think I've figured out what is so non-standard about them. There are three primary issues going on. Exceptions derived from ProException inherit a very poor implementation of ProException.ToString() . That implementation is suppressing some of the most valuable stuff for troubleshooting - stack details and inner exception(s) details. It probably would have been better to leave the ToString() alone, and use the implementation from the base class (Exception), especially if you omit the good stuff. Here is what Microsoft says about their implementation: The default implementation of ToString obtains the name of the class that threw the current exception, the message, the result of calling ToString on the inner exception, and the result of calling Environment.StackTrace. If any of these members is null, its value is not included in the returned string. None of the Progress exceptions ever bother to capture inner exception and *store* it! The ProException class has something that appears to be a Progress-specific replacement for the inner exception. It is called a "Previous" exception member. But in practice, Progress never bothers to put any information in here either, and it certainly doesn't show up in the output of ToString(). Aggressive catching and rethrowing exceptions, recharacterizing the root cause of any given problem. This is not a huge deal in itself (in fact, I would rather have my exceptions to be strongly typed, and to include as much valuable contextual detail as possible). But when you combine this with other two factors (mentioned above) then the original/root cause of an error becomes quickly buried and obscured. Here is the stack I was working with today. The root cause of the bug appears to be something basic (ie. static "Vector" members of HTTPConnection that aren't protected for concurrency). Again the bug itself doesn't bother me as much as the implementations of the openclient Exceptions themselves. The original exception is from ArrayList (because of the concurrent use of a class that isn't safe for threading). It is simply 'System.IndexOutOfRangeException' - Index was outside the bounds of the array . But soon this will be translated several times over until it looks totally different : " Unable to resolve hostname localhost ". (... which we would then send to our network team, so they can spin their wheels for a while, and buy us some time to restart the application ;-) Notice the red highlights in the callstack above. At each of those points, Progress interacts with the exception - catches and rethrows it. At each of those points the exception is translated and re-thrown. At each point, the inner exception, and the original callstack, is omitted! It reminds me of the children's game called telephone. Progress.o4glrt.dll!Progress.UBroker.Client.HttpClientProtocol.setupProxyServer Catches exception and changes to Progress.UBroker.Util.NetworkProtocolException ToString() output is simply "Progress.UBroker.Util.NetworkProtocolException: 9988" Thrown again like so: throw new NetworkProtocolException(x, y, z); /* NO INNER SUPPLIED */ Progress.o4glrt.dll!Progress.UBroker.Client.BrokerSystem.processConnect Catches exception and changes to Progress.Open4GL.Exceptions.ConnectProtocolException ToString output is simply "Progress.Open4GL.Exceptions.ConnectProtocolException: Invalid http protocol configuration: Failure removing localhost from proxy list: Index was outside the bounds of the array. (9988)" Thrown again like so : throw new ConnectProtocolException(x, y, z); /* NO INNER SUPPLIED */ Progress.o4glrt.dll!Progress.UBroker.Client.BrokerSystem.connect Catches exception and changes to Progress.Open4GL.Exceptions.UnknownHostnameException ToString output is simply "Progress.Open4GL.Exceptions.UnknownHostnameException: CONNECT FAILURE: Unable to resolve hostname localhost (8821) " Thrown again like so :throw new UnknownHostnameException(x); /* NO INNER SUPPLIED */ Progress.o4glrt.dll!Progress.Open4GL.DynamicAPI.SessionPool.BrokerSessionList.reserveSession Catches exception and changes to Progress.Open4GL.DynamicAPI.SessionPool.NoAvailableSessionsException ToString output is simply "Progress.Open4GL.DynamicAPI.SessionPool+NoAvailableSessionsException: SessionPool : NoAvailableSessions[CONNECT FAILURE: Unable to resolve hostname localhost (8821) ]" Thrown again like so: throw new SessionPool.NoAvailableSessionsException(x); /* NO INNER SUPPLIED */ APP_Production_Maintenance_Kiln_Proxy.dl l!UFP.LumberTrack.AppServer.Proxy.APP_Production_Maintenance_Kiln_Proxy.APP_Production_Maintenance_Kiln_Proxy Custom appobject constructor, created by proxygen... Catches exception and throws another instance of the same type that was caught (Progress.Open4GL.DynamicAPI.SessionPool.NoAvailableSessionsException) ToString output is simply "Progress.Open4GL.DynamicAPI.SessionPool+NoAvailableSessionsException: SessionPool : NoAvailableSessions[CONNECT FAILURE: Unable to resolve hostname localhost (8821) ]" This is the final exception that is observed by our custom code. To make a long story short, an exception is caused by a internal bug (a pretty basic one). But the exception itself gets retranslated *five* times and loses inner exceptions and callstacks and even the original exception message itself. It comes out the other end as something that is totally meaningless, and is useless for troubleshooting the root of the problem!
Continue reading...
Continue reading...