Кто нибудь пробовал логику работы с ошибками в Go засунуть

в JavaScript?

то есть:

export async function createSomeObject(id: string, data: DataInterface) {
// ...
if (response.status != 200) {
return {response: undefined, err: "status code is not 200"}
}
return {response: response, err: undefined}
}

const {resp, err} = createSomeObject()
if (!isUndefined(err)) {
// work with err
}

Пробовал

Но зачем, если в js для этого есть try catch

и как оно?

потому что система работы с ошибками в Go интереснее чем try catch 🙂

Также оборачивал, но в php. Первый элемент только был error, второй data (или result)

логичней наоборот

Почему? Сразу же error и проверяешь первым. Бтв, в js есть эти всякие null и undefined, их должно хватать без передачи массивами. Можно по подробнее?

читать проще file, err := getFile() чем err, file := getFile() приходится туды сюды

Если уже на то пошло, самое удачное прокалывание ошибок наверх в расте. не холивара ради. Просто там для этого есть знак вопроса вместо if err != nil return nil, err

Птс, вы про го, а в php и js вы же так не можете. Или я неверно понял?

не видел раст в глаза даже. поэтому не могу сказать. в свифте и в тайпскрипте есть знак вопроса - говорящий об опциональности переменной - так что можно как в расте, если я правильно понял

я про реализацию такого подхода (из го) в жс и да, в жс так можно. так везде можно ) я спрашиваю про целесообразность, читаемость, поддерижваемость если кто-то так делал в проекте

Там есть деструктуризация как массивов [data, err] = ... Так и деструктуризация объектов в js, так что все можно

А, сообразил, вы деструктуризацией делаете. Умно.

насчет умно - хз но да, деструктуризация

Да, спасибо, сообразил. Но в php действительно без разницы вроде. Но я пока не понял чем стандартная проверка через нулы и андефайнды плоха? Чисто от любви к go перегружать код? Js и так не слава богу язык, а тут такое.

Но лучше пользуйся try/catch и .tnen/.catch если оно уже есть в языке и общепринято

поэтому и спрашиваю про опыт )

Если ты не словить какую-то ошибку у тебя упадет все программа

Строго говоря она не интереснее. Но позволяет или уж хоронить ошибки сразу (у меня, например, куча мест без анализа error), или обработать их как можно быстрее, без протагивания наверх и кладбища на верхнем уровне UPDATE: ПРИНУЖДАЕТ

речь про клиентский js

интерес у каждого свой 🙂

Когда я сказал такое своему сеньору, мне дали по голове, но сказали, что то вроде "фиг с ним, потом перепилим".

такое это о чем?

Что пофигу же, что на клиенте, мы же не свой бекенд горбатим

пофигу что именно? что каждый раз деструкт и раскрывание?

Ну грубо говоря да. Просто со временем привыкаешь к оптимизации кода и везде ее ищешь в итоге. Фулстек сеньор.

а он прям показал бенчи этого подхода? найти оптимизацию и забенчить ее - это 2 разные вещи

Ну вот тут не могу сказать. Последний раз я видел сеньора с бенчами на работе - никогда.

такое себе 🙂

в Lua к примеру для обработки ошибок, есть pcall Но статус об ошибки идет первым элементом: err, result = pcall (func_test,func_arg)

Ну луа-то другое. Если я правильно помню, то второе значение строго говоря может не возвращаться, a в local e,, x = pcall(...) x будет равен nil не из-за того, что nil возвращают, а из-за того, что объявлена переменная локально.

Я про сам подход