Looking at the title I may have unfortunately chosen for this site, it reads similar to a “directive not found” inclusion common to SSI and ASP pages. “Bus error” is one of the POSIX generic error messages, and I’ve seen it twice. From my perspective as a developer, it’s possibly one of the worst error messages around for comprehensibility.
The first time I saw this message was while working on an OS X installation. I booted the system with the DVD and attempted to repartition the drive. However, the Disk Utility application refused to let me do so – simply crashing without any error message. When I launched the program from a Terminal window and replicated the crash… Bus error.
I later invoked the same message myself while testing a C/C++ application for my CS 241 class. The C and C++ languages were a new concept to me at the time, and I believe the specific error I made was trying to access unaligned memory. In this case, it was enough to let me know to verify my malloc() and free() calls before going ahead.
When I write informational, warning or error messages for my own applications, I try and follow this pattern:
- What is the immediate thing that’s wrong or needs to be addressed?
Bad: “Database error”
Good: “Could not connect to the database”
Better: “An invalid user name or password is preventing a connection to the database.”(I also keep in mind that these error messages may need to be tailored for specific user roles. For example, a site administrator should see the last message, where Web visitors should see generic/cached content with a “This site is not fully up to date, contact the site administrator” message.)
- Describe the error in more detail, providing additional information.
- If the error is based on user-provided settings, give additional help as to how to fix it.
Many situations that seem like they warrant an “error” message do not demand it at all. In an ideal application, the user shouldn’t have to see any harsh, STOP, don’t go there dialogs. One of the most common errors I see online is the “Connection to MySQL server failed” or “Too many connections to database server” message. Why is this message being shown?
- If there’s a legitimate load error, fall back to cached content with an informational message. Depending on traffic – such as to a specific article – you may be able to get away with replacing the content with a static HTML page. You do have cached content, correct? If not – why not? If your site is entirely database driven, there should be backups of the database.
- If there’s a configuration error – again, fall back to what content is available. Another design decision should be based on installation flags. Yes, the database server isn’t available because the username/password is incorrect: this is a given on the out-of-the-box installation of any Web application. Instead of completely giving up the towel, add a nice dialog that says “hey, you need to provide this information before your site starts working.”
- Don’t echo raw errors to the screen! They may reveal sensitive information or details about your site’s configuration. A way to do this with your own web apps: (these instructions assume you’re working with PHP)
- Create a function called d_echo that checks for a conditional $debug_enabled boolean variable. When debugging, have all potential error output displayed using this function.
- If $debug_enabled is true, have a BIG GLARING WARNING at the top of EVERY page noting that debugging mode is on and you should really turn it off, with a link available to do so.
- Allow debugging to be turned off from within the Web app itself, but don’t allow it to be turned back on without editing a configuration file. Debugging is for developers and testers – not a production environment.