Confusing dialog for contributed launch configs when errors occur

[sbatten]

Testing microsoft/vscode-python#19547

Steps:

1. Create a basic python script file in a new folder
2. Have the python extension installed
3. Go to the debug view container and select the "Show all automatic configurations" option
4. Choose Python... and File
5. Open the settings editor
6. Run the dynamic launch config

🐛 get a dialog about the ${file} variable and a button to open the launch.json

Neither of these apply since you didn't create the launch configuration nor does it exist in the launch.json

[roblourens]

I think that the message about "open an editor" will make sense to people, they should know what we mean. I can hide the launch.json button though.

[sbatten]

@roblourens In this case, the user didn't create any configuration. They got this auto configuration when they had the python file open. So they aren't necessarily familiar with the ${file} variable nor what an "editor" is. VS Code is open, so what does open an editor mean? Can we be more explicit? e.g. "A file must be open and ~active for running this configuration. Please open a file and try again".

[roblourens]

@alexr00 would it make sense to give the variable resolver a mode where it throws alternate error messages that don't assume that variable came from something that the user has control over?

I'm not sure, I think people will still figure out what this means

[roblourens]

Or you could put an id/enum field on the errors you throw so that the debug service can swap in its own error message, since @sbatten's example mentions "run this configuration" specifically.

[alexr00]

@alexr00 would it make sense to give the variable resolver a mode where it throws alternate error messages that don't assume that variable came from something that the user has control over?

The variable resolver only knows about variables. I think we always include the variable that failed in the error. Can you check for the specific variable that failed and show your own message based on that?

[roblourens]

You mean just check whether it shows up in the error message? I don't want to rely on that. I'm looking at these errors:

vscode/src/vs/workbench/services/configurationResolver/common/variableResolver.ts

Line 199 in cfd3c5c

throw new Error(localize('canNotResolveFile', "Variable {0} can not be resolved. Please open an editor.", match));

[alexr00]

Yes, that's the error I was referring too. If the match from that line is ${file} then you could use your own error message instead of the one from the variable resolver. We can also expand upon the Please open an editor if that would help.

[roblourens]

match is just getting plugged into the localized error message. I don't think it's safe to rely on a substring in an error message

[alexr00]

@roblourens what do you think about something like this: #157788

If that works for you then I'll add error kinds for other variables, not just file.

[roblourens]

Reopened for me to adopt

[roblourens]

Is there anything similar in tasks or any other consumer? A case where an extension generates a config with variables that get resolved, and the user never sees the variables?

[alexr00]

@meganrogge for tasks.

Yes, an extension that provides tasks can include variables in their task. If the user hasn't configured the tasks in tasks.json then you could end up in this situation.

[roblourens]

I guess the error message still has to be specific to debugging, which is what the user knows about, and we probably can't provide a useful generic error message that doesn't include the specific variable.

[roblourens]

Oh no. Sorry for taking so long to try to adopt this but I just learned something - you can't throw custom error types across our IPC. The variable resolver is running in the EH and in the renderer process, any extra properties on the error have just been lost. So I've got to take a look at what that code actually does.

[roblourens]

Well I should be able to capture the custom error type and send it back as a value, this all goes through the ExtHostDebugService. Should be no problem.