Coding Horror: What's worse than a Bad Error Message?

June 24, 2004

What's worse than a Bad Error Message?

I'm sure I don't have to explain what is wrong with error messages like this:

Catastrophic Failure
General Protection Fault
Error: The operation completed successfully.

But as bad as those are, they pale in comparsion to what is, hands down, the worst kind of error message: a beautiful, well-formatted, informative, incorrect error message.

Due to the issue documented in my previous post, we're currently replacing the database layer of our production application-- switching from Microsoft's System.Data.OracleClient, to Oracle's Oracle.DataAccess. Just what you want to do in a production system, make sweeping changes in the back end soon after deployment. Er, right. But I digress.

The initial conversion went better than expected, and ran fine on development machines within a few hours. However, when we deployed our Smart Client app, we encountered the following exception:

(Inner Exception)

Exception Source:      Oracle.DataAccess
Exception Type:        System.DllNotFoundException
Exception Message:     Unable to load DLL (OraOps9.dll).
Exception Target Site: GetRegTraceInfo

---- Stack Trace ----
   Oracle.DataAccess.Client.OpsTrace.GetRegTraceInfo(TrcLevel As UInt32&)
       CrazyApp.Loader.EXE: N 00000
   Oracle.DataAccess.Client.OracleConnection..ctor()
       CrazyApp.Loader.EXE: N 00032
   SharedUtils.DB.DBDataset..ctor(info As SerializationInfo, context As StreamingContext)
       CrazyApp.Loader.EXE: N 00040
       
(Outer Exception)

Exception Source:      mscorlib
Exception Type:        System.Reflection.TargetInvocationException
Exception Message:     Exception has been thrown by the target of an invocation.
Exception Target Site: HandleReturnMessage

---- Stack Trace ----
   System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(reqMsg As IMessage, retMsg As IMessage)
       CrazyApp.Loader.EXE: N 00264
   System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(msgData As MessageData&, type As Int32)
       CrazyApp.Loader.EXE: N 00682
   CrazyApp.API.UserManager.GetUser(dsUser As DataSet&)
       CrazyApp.Loader.EXE: N 00000
   CrazyApp.UI.Data.ClientDatasetManager.GetCurrentUserDataset(blnForceRefresh As Boolean)
       CrazyApp.Loader.EXE: N 00081

Thus began an entire day of hair-pulling exercises in determining why the remoted Oracle call can't locate OraOps9.dll. It has to be a configuration problem on the server with the Oracle driver. Just like the nicely formatted error message says, with its informative stack traces and exception details. Right?

Wrong. After exhausting every possible scenario-- I wish I could say it was skill, but it's a lot more like dogged trial and error-- we determined that, despite the fact that the exception is wrapped in a remoting call, the required file is missing from the client!

I discovered this on my own machine. Intellectually, I knew there was no way I could be getting different results from a server call than any other client. The only possible explanation was a new client dependency introduced by referencing types in Oracle.DataAccess. But I still refused to believe this. In fact, I did not believe it until I duplicated it, by installing the Oracle 9 client and .NET layer on a clean build machine. Sure enough, the smart client app ran fine as soon as I did that.

I've probably spent more time chasing down erroneous error messages than the time I've spent on all other error messages combined. Evidently computers, like people, are big fat stinkin' liars!

Posted by Jeff Atwood View blog reactions

« Debugging ASPNET_WP in Production UNIX will never be usable »

Comments

Oracle 9.2 Client software requires that you give the Authenticated User privilege to the Oracle Home by following steps:

1. Log on to Windows as a user with Administrator privileges.
2. Launch Windows Explorer from the Start Menu and and navigate to the ORACLE_HOME folder.
This is typically the "Ora92" folder under the"Oracle" folder (i.e. C:\Oracle\Ora92).
3. Right-click on the ORACLE_HOME folder and choose the "Properties" option from the drop down menu. A "Properties" window should appear.
4. Click on the "Security" tab of the "Properties" window.
5. Click on "Authenticated Users" item in the "Name" list (If none, Please Click "Add" button To Add it in).
6. Uncheck the "Read and Execute" box in the "Permissions" list under the "Allow" column.
7. Re-check the "Read and Execute" box under the "Allow" column (this is the box you just unchecked).
8. Click the "Advanced" button and in the "Permission Entries" list make sure you see the "Authenticated Users" listed there with:
Permission = Read & ExecuteApply To = This folder, subfolders and files.
If this is NOT the case, edit that line and make sure the "Apply onto"drop-down box is set to "This folder, subfolders and files".
This should already be set properly but it is important that you verify this.
9. Click the "Ok" button until you close out all of the security propertieswindows.
The cursor may present the hour glass for a few seconds as it applies the permissions you just changed to all subfolders and files.
10. Reboot your computer to assure that these changes have taken effect. Re-execute the application and it should now work.

-------------------------------------------
Good Luck

alex zhang on May 25, 2005 10:18 PM

The call in question was executing on the server, not the client. There's a bizarre client dependency when using remoting and Oracle.DataAccess. The client isn't making any database calls, it is invoking HTTP proxy classes which actually execute on the server (eg, Remoting).

Jeff Atwood on May 25, 2005 11:54 PM

Well, came across this post and I'm feeling better already, I'm not the only one who has suffered ;)

Haven't figured out yet what is causing it but here is the error (partial stack removed).
TargetSite : Void HandleReturnMessage(System.Runtime.Remoting.Messaging.IMessage, System.Runtime.Remoting.Messaging.IMessage)
Stack Trace : Server stack trace: at {Class Name}.ReplaceText(Object objectName, String text) in {File Path}:line 446

And here is the offending 'Remoting.Messaging.IMessage' error, didn't realize a string replace command was now a Remoting Call Microsoft:
returnValue = returnValue.Replace("@Date", Object.Date.ToShortDateString)

Worked fine all day and then when I VPN'd in again tonight to deploy to production I get this joyous pain in the rear. The funny (or sad I guess) thing is there were no new dependencies or anything put in the code today, only minor bug fixes before deployment!

Joe on December 10, 2005 01:21 AM