> В C++ было бы исключение, которое было бы поймано и обработано. В
> Rust исключений нет, поэтому паника на любой чих.Оно было бы обработано примерно так:
int main() {
try {
real_main();
} catch (...) {
cerr << "Spurious exception caught. Some of us, stupid coders did something nasty.";
return -1;
}
}
Может быть это происходило бы не в main'е, а где-то ещё, но в любом случае, с точки зрения программы это бы выглядело как "непредвиденное исключение вылетело, единстсвенный выход -- упасть, сделав вид, что не упал".
Если тебе непонятно почему, то почитай этот самый issue, и представь себе, что программа написана на C++, что вылетает не паника, а исключение, но просто оно не обрабатывается в программе. И теперь твоя задача выбрать место, где воткнуть try {} catch (OutOfBoundException e) /*или как там это в C называется?*/. Попробуй выбрать какой-нибудь из стековых фреймов где это исключение должно быть обработано и аргументируй свой выбор.
Вот тебе код connect_gtk, на стековом фрейме которой случается попытка доступа за границы массива:
pub fn connect_gtk(&self) {
self.connect_headerbars();
self.connect_login_view();
self.connect_send();
self.connect_markdown();
self.connect_autocomplete();
self.connect_directory();
self.connect_leave_room_dialog();
self.connect_new_room_dialog();
self.connect_join_room_dialog();
self.connect_account_settings();
self.connect_invite_dialog();
self.connect_invite_user();
self.connect_direct_chat();
self.connect_roomlist_search();
}
Допустим, я заверну всё это в try {} catch (...) {}, и теперь вопрос: будет ли допустимым продолжать выполнение программы, если мы получили здесь OutOfBoundsException? Или может надо сделать несоколько блоков try, и из некоторых падать, а из некоторых продолжать? Расскажи нам, как бы здесь C++ программист обрабатывал бы исключение, и как бы ему удалось решить проблему без падения.
А если тебе до сих пор ещё неясно, то я могу копнуть ещё глубже. connect_headerbars (который вероятно был заинлайнен, и поэтому не имеет самостоятельного стекового фрейма в release) содержит такие строчки:
if let Some(decor) = set.get_property_gtk_decoration_layout() {
let decor = decor.to_string();
let decor_split: Vec<String> =
decor.splitn(2, ':').map(|s| s.to_string()).collect();
if decor_split[1].contains("close") {
right_header.set_show_close_button(false);
left_header.set_show_close_button(true);
} else {
left_header.set_show_close_button(false);
right_header.set_show_close_button(true);
}
}
Тут есть индексация в decor_splitn, которая предполагает, что там будет хотя бы два элемента, то есть что set.get_property_gtk_decoration_layout() вернула строчку, в которой есть хотя бы один символ ':'. Я не знаю, насколько такое предположение допустимо, но предположим что нет. А автор кода, очевидно считает, что да. Это предполагаемое заблуждение автора ведь никак не связано с выбором языка программирования, так? И вероятно именно оно, приводит к вылету паники или в случае C++ исключения. Расскажи как в этой гипотетической ситуации исключения C++ вместо паники rust'а сделали бы поведение программы лучше.
ps. Тут четыре выделения памяти: одно под Vec, и ещё три под String, и вся эта память освобождается обратно, после завершения внешнего if'а. И если let decor = decor.to_string(), я предполагаю, связан с тем, что gtk'шная функция возвращает что-нибудь типа CStr, и чтобы задействовать rust'овую библиотеку для работы со строками, нам необходимо сделать из него rust'овую строку (хотя всё равно я не понимаю зачем он нужен), то три оставшихся только ради того, чтобы выполнить один if с read-only доступом к decor_split[1]. И при этом, тут есть как раз потенциальная паника, если decor_split содержит меньше двух элементов.
Вместо этого ведь можно:
if decor.split(":").skip(1).map(|s| s.contains("close")).next() == Some(true) {
right_header.set_show_close_button(false);
left_header.set_show_close_button(true);
} else {
left_header.set_show_close_button(false);
right_header.set_show_close_button(true);
}
Осталось только одна пара malloc/free, тоже по-моему ненужная, но это не очень важно поскольку в любом случае это O(1) добавленной сложности для программы, а что важно, так это то, что мы больше не полагаемся на то, что splitn вернёт нам хотя бы один элемент.
Я бы объяснил им, как надо, но не знаю, как на gitlab зарегаться или залогиниться. У меня не выходит, а разбираться в чём там дело я не буду.
