| The stack trace in an exception is very useful information for debugging. It has the location of where the error occurred. It has the order of calls made until that function was executed. So, the developer is tempted to show that information on the screen, when an error happens. However, this should not be the case, since the average user is not a programmer and will understandably be confused. It also reveals the internals of the software (including the bugs), which should generally be avoided with proprietary work.Since you can’t use exceptions for information level and warning level logging, the best place to store information for debugging is the log. The log can have information other than what’s included in an exception. Information can be logged with parameters that invoked the program. The values of the arguments to a function would also be beneficial for reproducing the problem.
Because exceptions can get lost, this information should be recorded when the exception is raised, not when it is caught. For example, you would need to extinguish exceptions in a destructor, a function may throw an exception in a finally clause, and there may be cases when an innocent developer forgot to fill in the catch clause. If you define exception classes to automatically log information in the constructor, you wouldn’t forget to do it. The log may be accessible on the UI as a hidden feature. Some products allow terminals to be connected to it, so that the log can be retrieved. If the device is connected to the internet, there might be a button to send the log to the manufacturer encrypted and compressed. |
Contents |