We have a closed-source commercial C++ application. Some of our logged error messages are in plain English like "ERROR: could not read file 'foo'". While others use a macro to print filename/line information like ""SplineReticulator.cpp(423): out of bounds". This is not an assert or a crash, the application recovers fine, but it's an error we want to log.

What is a good rule of thumb when plain-English error message is appropriate vs. a filename/line one? Or are filename/line type errors even appropriate for closed-source commercial software? We've heard the argument they are unprofessional looking, but they are handy for debugging.

  • If you don't want to disclose file/line information, you can replace it by a GUID. File/line information is just a grep away and users can clearly identify these logs as debug data for maintainers.
    – mouviciel
    Sep 11, 2013 at 5:29

2 Answers 2


If your application produces a log file, then put all your module name/line number stuff in there. The errors for the user should be in plain $usersLocalLanguage whenever possible. If you need the detailed info while trouble-shooting a client's problem, you can get the user to email the log file to you, and dissect that all you want.

If you don't have a log file, then you might want to have a dialogue box that has a simple error for the user, and then a "details" panel (closed, by default) where they can copy the tech details (with filename/line number) and paste into an email and send it to you.


Our guideline is that technical details are only logged at debug level. All other messages are for customer consumption and must be worded appropriately with a minimum of technical jargon.(mere humans must be able to understand. :-)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.