starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Possibly expose exception text on error dialog #1330

New Issue
Closed
opened 2026-01-30 22:22:45 +00:00 by claunia · 7 comments
claunia commented 2026-01-30 22:22:45 +00:00
Owner
Copy Link

Originally created by @zadjii-msft on GitHub (May 24, 2019).

Right now we display an error dialog if there was an exception parsing the settings.

We should potentially also add the exception test to that dialog, so the user can see exactly where the parsing went wrong.

This is also dependent upon #475, where I'm adding support for jsoncpp, We can throw an exception with a decent message there, but we need to make sure it's actually displayed.

Preferably, the exception text would

  1. Be copyable
  2. Be collapsible (so the user sees our message first, then can expand the "details")
Originally created by @zadjii-msft on GitHub (May 24, 2019). Right now we display an error dialog if there was an exception parsing the settings. We should potentially also add the exception test to that dialog, so the user can see exactly where the parsing went wrong. This is also dependent upon #475, where I'm adding support for `jsoncpp`, We can throw an exception with a decent message there, but we need to make sure it's actually displayed. Preferably, the exception text would 1. Be copyable 2. Be collapsible (so the user sees our message first, then can expand the "details")
claunia commented 2026-01-30 22:22:46 +00:00
Author
Owner
Copy Link

@dlong11 commented on GitHub (May 25, 2019):

@zadjii-msft Wouldn't this cause localization issues? Or are you thinking the exceptions strings will be resources that are translated? Or do you think the details can always be English?

@dlong11 commented on GitHub (May 25, 2019): @zadjii-msft Wouldn't this cause localization issues? Or are you thinking the exceptions strings will be resources that are translated? Or do you think the details can always be English?
claunia commented 2026-01-30 22:22:46 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 28, 2019):

I think if we're displaying raw exception text, then that can just be in whatever locale the exception is originally. That would make searching for the exception text certainly easier

@zadjii-msft commented on GitHub (May 28, 2019): I think if we're displaying raw exception text, then that can just be in whatever locale the exception is originally. That would make searching for the exception text certainly easier
claunia commented 2026-01-30 22:22:46 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (May 28, 2019):

Stretch goal: add a copy button that puts the exc text on the clipboard ;P

@DHowett-MSFT commented on GitHub (May 28, 2019): Stretch goal: add a copy button that puts the exc text on the clipboard ;P
claunia commented 2026-01-30 22:22:47 +00:00
Author
Owner
Copy Link

@dlong11 commented on GitHub (May 29, 2019):

@zadjii-msft - I am not sure if I stated my question clearly.

In the description you mention

We can throw an exception with a decent message there, but we need to make sure it's actually displayed.

My question is the "decent message" you mentioned above - Is this going to be translated? Or will this be English? This feature seems helpful but it also seems weird that if I am running under the German locale the exception text will be in English. (if the plan is not to translate the exception messages)

I hope this makes sense. English in these scenarios might OK, I am just trying to figure out what the plan is.

@dlong11 commented on GitHub (May 29, 2019): @zadjii-msft - I am not sure if I stated my question clearly. In the description you mention > We can throw an exception with a decent message there, but we need to make sure it's actually displayed. My question is the "decent message" you mentioned above - Is this going to be translated? Or will this be English? This feature seems helpful but it also seems weird that if I am running under the German locale the exception text will be in English. (if the plan is not to translate the exception messages) I hope this makes sense. English in these scenarios might OK, I am just trying to figure out what the plan is.
claunia commented 2026-01-30 22:22:47 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 29, 2019):

Ah see, I was thinking that error messages would have two sets of text.

  1. The error message that we primarily display to the user
  2. The raw exception text

1 would be localized, and would be text that we write ourselves. "Failed to load the settings file", etc. This text would always be displayed to the user. This is the text we have currently in the ContentDialog.

2 would not be localized, as it would be straight from whoever was throwing the exception. The case I'm thinking of would be exceptions thrown by jsoncpp, where it states the line and column where it failed to parse the file. This would only be displayed to the user when they chose to expand the exception text. Because it's not locale-specific, it would be easier to search the web for that exact exception text, and find solutions.

I don't think we'd be capable of generically translating arbitrary exception messages from third-party libraries we might use.

With this model, we'd be able to have both a localized message the user can use to understand the message, and a specific message they can use to try and debug (or get help from us :P)

@zadjii-msft commented on GitHub (May 29, 2019): Ah see, I was thinking that error messages would have two sets of text. 1. The error message that we primarily display to the user 2. The raw exception text 1 would be localized, and would be text that we write ourselves. "Failed to load the settings file", etc. This text would always be displayed to the user. This is the text we have currently in the ContentDialog. 2 would not be localized, as it would be straight from whoever was throwing the exception. The case I'm thinking of would be exceptions thrown by jsoncpp, where it states the line and column where it failed to parse the file. This would only be displayed to the user when they chose to expand the exception text. Because it's not locale-specific, it would be easier to search the web for that _exact_ exception text, and find solutions. I don't think we'd be capable of generically translating arbitrary exception messages from third-party libraries we might use. With this model, we'd be able to have both a localized message the user can use to understand the message, and a specific message they can use to try and debug (or get help from us :P)
claunia commented 2026-01-30 22:22:47 +00:00
Author
Owner
Copy Link

@dlong11 commented on GitHub (May 30, 2019):

@zadjii-msft Thanks! This was what I was looking for. 😄 I was wondering how you were going to convert third party exceptions. In the .NET world you are expected to translate your exception messages. In your scenario that would be a good thing, but in general, it always seemed a little weird.

@dlong11 commented on GitHub (May 30, 2019): @zadjii-msft Thanks! This was what I was looking for. 😄 I was wondering how you were going to convert third party exceptions. In the .NET world you are [expected to translate your exception](https://docs.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions#include-a-localized-string-message-in-every-exception) messages. In your scenario that would be a good thing, but in general, it always seemed a little weird.
claunia commented 2026-01-30 22:22:47 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Aug 27, 2019):

:tada:This issue was addressed in #2422, which has now been successfully released as Windows Terminal Preview v0.4.2382.0.🎉

Handy links:

@ghost commented on GitHub (Aug 27, 2019): :tada:This issue was addressed in #2422, which has now been successfully released as `Windows Terminal Preview v0.4.2382.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.4.2382.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-UserInterface Issue-Task Product-Terminal Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#1330
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?