| Date: | January 29, 2018 / year-entry #25 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20180129-00/?p=97915 |
| Comments: | 17 |
| Summary: | I guess they don't know what went wrong either. |
I guess the tool doesn't know what went wrong either. Maybe the error message could have been
On the other hand, that could very well have been the error message it wanted to print, except that the characters didn't survive the translation to the OEM code page. |
Comments (17)
|
Somewhere in the source for that project are the lines:
switch(result)
{
…
default:
std::count << "????" //This will never happen.
}
“Confusion wiggles!” is a real error in Fontforge, a typeface editor for GNU/Linux.
It’s emitted during removal of lines that overlap themselves, which are not allowed to appear in font data; and basically, an assertion for something that should never happen. Yet I get 20+ dialogs of “Confusion wiggles!” when I try to convert quadratic splines to cubic splines (an inexact process, that also needs to be rounded to integers).
There are also “Confusion reighns!” and “Confusion regnas!” as well.
To clarify, it’s not because overlapping lines can’t appear in font data, that this error message should never happen, but that there are some conditions during the removal that are not supposed to happen.
Six of the nine characters of ¯\_(ツ)_/¯ (the underscores, both brackets, and the forward and reverse slashes) are in the plain ASCII subset, so they should have survived the translation. If it were a codepage problem, the result should have been like ?\_(?)_/? (which, now that I look at it, is a bit surreal, and perhaps more fitting for an unknown error).
By the way, a version in ANSI (or Latin-1, or Windows 1252, or whatever someone else wants name it) would be ¯\_(¨)_/¯ (the “superscore” is part of the ANSI subset, with code 175, and so is the dieresis). I find the superscore specially useful to underline titles in plain text documents, so I have learned its code to enter it quickly (WYSIWYG? We don’t need no WYSIWYG! Real men format their documents by hand! ;-) ).
Why would KATAKANA LETTER TSU transliterate to a spacing diaeresis?
Semantically, it wouldn’t. A human bean might make the substitution in search of a particular appearance.
To read the error message in its native language do chcp 65001 and retry the command. Most of the historic bugs in chcp 65001 have been fixed in Windows 10 and I can copy, paste, and edit Unicode fragments in the command interpreter now.
I was wondering if anyone else had figured out the ?s were the “command prompt can’t print this” character and not a real question mark.
If the application supports console redirection and is safe to re-run, rerun it and redirect the output to text file then open in a web browser will generally do the trick.
That’s because you didn’t guess a letter contained in the word.
If you cause it to fail again, you can guess a letter each time. It’s “Hangman Errors”.
c:\src\blah\mumbletool : error error: ??????a???a????
It’s not the least useful error message that I’ve ever seen. I’ve seen ones that print the equivalent of “an error occurred. Please contact your administrator for support”. The “?????” one, at least, tells me that there’s a code page mismatch somewhere along the line that I could fix.
This wasn’t just an error: it was an *error error*! Does that mean that something bad happened in the exception-handling code?
https://cdn.windowsreport.com/wp-content/uploads/2016/02/something-happened.jpg
My favorite is “An error has occurred: The operation completed successfully”
Have you ever tried to do a real-world app using UWP?
There are “Something happened”, “Unknown error” etc. all over the WinRT XAML framework. You just can’t debug UWP.
You may have noticed that the “Oops” and “Something happened” error message style is trending across all apps, not just UWP apps.
I noticed, and that makes me very sad.
But I was especially fed up with XAML/WinRT development (starting with Windows 8.1 and continuing to Windows 10). Unlike WPF which is literally being killed off, UWP is extremely hard to debug. And then, if you have tools like HockeyApp that hook into Application.OnUnhandledException event and do anything with the exception, debugging XAML becomes impossible at all.