Proposal: LSP Inlay Hints for raises
Background: What are Inlay Hints?
Inlay hints are a feature provided by the Language Server Protocol (LSP) and supported by modern editors like VSCode. They inject helpful information directly into the editor’s source code view without modifying the actual file content.
For example, in languages like Python, Rust, or TypeScript, if you hold down a modifier key (like Ctrl+Alt in VSCode) or toggle the setting, the editor will display inline annotations for inferred types or parameter names. This gives developers immediate context without needing to hover over every variable or function.
The Problem
In Mojo, when reading through a function that can raise errors, it can be challenging to determine which specific function calls might throw an exception just by reading the code.
Currently, developers have to either:
- Hover over every single function call to check its signature.
- Rely on naming conventions to guess if a function raises.
- Jump to the definitions of the invoked functions.
When debugging an unexpected exception, writing robust error handling, or doing code review, this lack of immediate visibility slows down the development process.
The Solution: Inlay Hints for Exceptions
We can leverage the existing LSP inlay hint mechanism to annotate function calls that can raise. By toggling inlay hints, developers could instantly see which calls are fallible.
Example
Consider the following code snippet. In a normal view, it’s not immediately obvious which functions are fallible.
Normal clean view (Actual source code):
def process_data() raises:
load_config("config.json")
parse_data(1, 2, 3)
transform_data()
save_results("output.json")
With raises inlay hints toggled ON (Editor view):
def process_data() raises:
load_config("config.json") /* raises */
parse_data(1, 2, 3)
transform_data() /* raises ValueError */
save_results("output.json") /* raises IOError */
(Note: /* raises ... */ represents the visually distinct, semi-transparent inlay hint rendered by the editor, not an actual comment in the code).
Benefits
- Improved Readability: Instantly identifies fallible operations without cluttering the actual source code with boilerplate.
- Better Error Handling: Helps developers quickly spot where they might want to add explicit
try/exceptblocks instead of letting exceptions propagate silently. - Seamless Integration: Uses an established LSP paradigm that users are already familiar with for type hints.
Future Considerations
If this proposal is accepted, and as Mojo’s tooling evolves to support more inlay hints (e.g., parameter names, inferred types), it would be beneficial to provide granular configuration options in the LSP settings. This would allow developers to toggle specific categories of hints independently. For instance, a developer could choose to keep parameter name hints active while disabling raises hints if they don’t find them necessary.
This feature, if implemented, would significantly enhance the developer experience in Mojo, making error-prone code paths visible at a glance while preserving the clean aesthetic of the language.