Error messages should be descriptive, contextual, and self-identifying to aid debugging and user understanding. Include relevant context like method names, parameter values, or identifiers that help locate the source of the error.
Key principles:
Examples:
// Poor: Generic error without context
LOG(ERROR) << "Unable to initialize logging from handle.";
// Better: Descriptive with context and actionable guidance
LOG(FATAL) << "Unable to open nul device needed for initialization, aborting startup. "
<< "As a workaround, try starting with --" << switches::kNoStdioInit;
// Poor: Missing context
isolate->ThrowException(v8::Exception::Error(
gin::StringToV8(isolate, "Unknown error")));
// Better: Self-identifying with context
isolate->ThrowException(v8::Exception::Error(
gin::StringToV8(isolate, "Failed to retrieve target context for world ID: " + std::to_string(world_id))));
// Poor: Generic error
gin_helper::internal::ReplyChannel::Create(isolate, std::move(callback))
->SendError("WebContents does not exist");
// Better: Include channel context for debugging
gin_helper::internal::ReplyChannel::Create(isolate, std::move(callback))
->SendError("WebContents does not exist for channel: " + channel);
This approach transforms cryptic errors into meaningful diagnostics that developers can act upon, reducing debugging time and improving the overall development experience.
Enter the URL of a public GitHub repository