документацию win api изучить

Было бы здорово посмотреть. Есть репозиторий в GitHub-е?

Во кстати, я все не могу понять, как и когда эту функцию использовать. Обычно ведь ошибку оборачивают, когда хотят сделать ее описание более конкретным и отличать ее от другой ошибки которая произошла по той же причине. Как после этого извлечь эти детали понятно, а как извлечь саму ошибку без деталей, не ясно совсем. Например создал я 2 кастомные ошибки, хоть у них и одна причина:

fooErr := fmt.Errorf("Error while reading foo, reason: %w", io.EOF)
barErr := fmt.Errorf("Error while reading bar, reason: %w", io.EOF)

Как потом работать с fooErr и barErr? Как их различать и как пользователю отобразить их без того что внутри %w. Или я эту концепцию неверно понял вообще?

вот библиотека, которая юзает виндовз апи в хвост и гриву для гуи https://github.com/lxn/walk

Привет, ребята. Хочу создать программу для отслеживания работы сети компьютеров. И возникает вопрос как обстоять дела Go с Windows API? Нормально или все же на C# писать программу? (C# я не знаю)

вроде норм все. dll подключаются, функции вызываются

очень хорошо, на самом деле

в каком смысле? нельзя наследовать от двух ошибок?

а зачем бы это было нужно?

Во кстати, я все не могу понять, как и когда эту функцию использовать. Обычно ведь ошибку оборачивают, когда хотят сделать ее описание более конкретным и отличать ее от другой ошибки которая произошла по той же причине. Как после этого извлечь эти детали понятно, а как извлечь саму ошибку без деталей, не ясно совсем. Например создал я 2 кастомные ошибки, хоть у них и одна причина:

fooErr := fmt.Errorf("Error while reading foo, reason: %w", io.EOF)
barErr := fmt.Errorf("Error while reading bar, reason: %w", io.EOF)

Как потом работать с fooErr и barErr? Как их различать и как пользователю отобразить их без того что внутри %w. Или я эту концепцию неверно понял вообще?

а зачем бы это было нужно?

вот это интересный момент и это как раз про frm.Errorf("%w %w") :)

ну то есть изначально fmt.Errorf("bla bla: %w", io.EOF) это всегда одна и таже ошибка вне зависимости от текста и работать с этим надо как с одной ошибкой

хуже если надо передать например ошибку и причину этой ошибки и поведение может отличаться взавимости и от самой ошибки и от причины. Ну это как рза те кейсы для которых уже не подходят ошибки константы. и лучше делать свои типы

Да, я про то же, как правило, причина важна для того чтобы потом понять что реально случилось, а "контекст" (Сообщение сверху), важно отдать пользователю, при этом не вскрывая детали которые пользователь все равно не поймет (а иногда и знать не должен). И как в этом случае быть с этой фунцкиией? Она кажется не решает эту проблему совсем. Кажется эту функцию есть смысл использовать только в том случае, когда важна ошибка внутри %w и ее позже хочется вытащить и че то с ней сделать.

например, считывание ответа из Reader было прервано внешним фактором и логически это ErrorProtocol, а фактически context.Canceled и нужно в разных местах по разному это обработать

тогда это ErrorProtocol в которую вложен context.Canceled?

Да, я про то же, как правило, причина важна для того чтобы потом понять что реально случилось, а "контекст" (Сообщение сверху), важно отдать пользователю, при этом не вскрывая детали которые пользователь все равно не поймет (а иногда и знать не должен). И как в этом случае быть с этой фунцкиией? Она кажется не решает эту проблему совсем. Кажется эту функцию есть смысл использовать только в том случае, когда важна ошибка внутри %w и ее позже хочется вытащить и че то с ней сделать.

EOF оборачивать не положено

я боюсь, коллеги, сейчас вы изобретете иерархию ошибок в java

и на этом идея стухнет, потому, что ниасиляторы повсюду