I suspect that all non-trivial software is more likely to encounter situations where it is confronted with an external problem that it cannot work with, and therefore must fail. This may be due to poor configuration, lack of an external server, disk full, etc.
In these situations, especially if the software runs in non-interactive mode, I expect that all that can really be done is to log an error and wait for the administrator to read the logs and fix the problem. If someone sometimes interacts with the software, for example, a request arrives at a server that could not initialize correctly, then perhaps a hint can be given to check the logs, and maybe even an error may be reflected (depending on can you tell if they are a technical guy, not a business user). For now, though don't think too much about this part.
My question is, to what extent should the software be responsible for trying to explain the significance of a fatal error? In general, how much authority / knowledge can you allow yourself on software administrators, and how much should you include troubleshooting information and possible resolution steps when registering fatal errors? Of course, if there is something unique to the runtime context, it must be registered; but suggests that your software needs to talk to Active Directory through LDAP and get the error message "[LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece]"Is it reasonable to assume that the maintainers will be able to provide the error code to Google and decide what it means, or will the program try to analyze the error code and log that it is caused by an invalid user DN in the LDAP configuration?
, , .