No, the best that you can do is paste it into Google.
Giving a user an error ID gives them a partially-if-not-completely unique identifier that they can then use to find other people struggling with the same error and possible solutions.
This is infinitely better than having no error message and having to try to type different permutations of your symptoms into Google in order to try to win search engine bingo.
Sure, if Apple quickly and responsively fixed issues, then you wouldn't need the error code. But, they don't! The problem is that "hide the error message and replace with actionable advice" only works in the idealistic case where the vendor will quickly fix the issue and/or the advice consistently fixes the problem. But, they don't, and it doesn't - the advice doesn't work unless implemented flawlessly - it's not robust.
The robust approach that will actually survive contact with the real world is "include an error message and ID code - even if you have to hide it behind a "more details" button".
Or worse, the fix suggestion being wrong: "Please try again later", when the root cause is a misconfiguration, so it'll never work until the configuration is corrected.
And if it's a program display it in some fashion where it can be selected so you can ^c^v it rather than have to retype it. Such errors are all too often displayed on non-selectable labels.
Bonus points to the mythical developer that includes a google-this button on the error display.
Giving a user an error ID gives them a partially-if-not-completely unique identifier that they can then use to find other people struggling with the same error and possible solutions.
This is infinitely better than having no error message and having to try to type different permutations of your symptoms into Google in order to try to win search engine bingo.
Sure, if Apple quickly and responsively fixed issues, then you wouldn't need the error code. But, they don't! The problem is that "hide the error message and replace with actionable advice" only works in the idealistic case where the vendor will quickly fix the issue and/or the advice consistently fixes the problem. But, they don't, and it doesn't - the advice doesn't work unless implemented flawlessly - it's not robust.
The robust approach that will actually survive contact with the real world is "include an error message and ID code - even if you have to hide it behind a "more details" button".