1

In my earlier project I wrote an app that is used in-house. My usual practice is to capture errors/exceptions from different classes and threads and put them in different log files corresponding to different classes and threads grouped logically. And few simplified errors I targeted to the text area in the UI. So user is presented with only simplified user friendly error explanation. And when the app stuck/hang, I simply used to fetch the detailed logs and find out what was going wring from the stack trace in there. This allowed me to quickly and precisely diagnose issue many times.

Now I am in new project and people here dont print stack trace at all in any file. They simply write whats going wrong in some files, and check those file in hang ups and guess what might be wrong. They might be able to do this, since they are handling this piece of software for long and their guessing works many times. But thats not possible for me, since I am new in this project and I cant guess anything.

So the question boils down to many small questions:

  1. Is putting stack trace in files is bad? Since writing to files has nothing to do with UX, is just that security issue that makes it look bad idea?
  2. If answer to first question is Yes, then does the concept of stacktrace is meant to be used only during the development time?
  3. If answer to first question is Yes, then is it a wise way to put simplified error messages in files and then do guessing?
  4. What are standard approaches followed in the industry?

1 Answer 1

4

Is putting stack trace in files is bad? Since writing to files has nothing to do with UX, is just that security issue that makes it look bad idea?

No it is not a bad thing. It is a good thing.

Fatal errors need consistent and clear logs and information to attempt to reproduce the error, verify the error seen, triage, resolution and then testing. Depending on the target environment, crash dumps are not always possible or feasible to get hold of. Developer focused logs are very useful.

I would expect a few things to be in that log, inter alia;

  • Stack trace (where)
  • The actual error or exception (what)
  • Any inner exceptions (how)
  • Function argument values (when)
  • Possibly the user rights (who)
  • Date and time for cross referencing
  • Possibly a user description of what they were doing, this may be tied to the bug report filing

On the security issue, if there is sensitive data in the log, it will then need to be sanitised or encrypted. Deal with the security, but don't let it obscure the error.

Crash dump files and ilk are a well known concept. Use them judiciously and they are very helpful and useful.

2
  • Yeah those variables I used to log in separate files. About the security issue, some consider that stacktrace may expose the package / class hierarchy of the app. Was just thinking if that is really very risky stuff
    – Mahesha999
    Aug 3, 2015 at 8:23
  • The exact location of all the detail is up to you. You don't mention the language used, but simple reflection can expose a lot of this "sensitive data" anyway. If concerned, some basic encryption should clear that up. For more detail or input on the security, you could always give the security.stackexchange.com a visit and see if they have more detail on it.
    – Niall
    Aug 3, 2015 at 8:28

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