Не знаю, я не люблю паники и считаю их такой ошибкой, которую и ловить не надо - их вообще не должно быть в коде. Так что если она падает, то это хороший сигнал, что стоить переписать фрагмент с паникой. Обычно обрабатывают результат. Ну ок, в крайнем случае можно поймать панику в корне с помощью чототам_unwind из стд
Почему штуки могут не дропнуться? При панике ведь будет раскрутка стека, растовое RAII должно ведь отработать
То что полностью инициализировалось - да. А если объект на половине сломался? Как его дропнуть?
Можно пример такого полуготового объекта? Насколько я понимаю, это в целом плохая практика, оставлять полуготовые объекты
Подробнее написано в RefUnwindSafe. Но если честно, то не припомню объектов, которые не имплят этот трейт. Возможно, их и нет в стд. Во всяком случае, на панику вообще не стоит надеяться - может быть что угодно. Как, например, то что я назвал уже
Касательно паники я согласен, но встречал и данное мнение: если в программе происходит что-то прям непоправимое, и обработать адекватно нельзя, нужно кидать панику, а не result. Это привело к тому, что на глаз 30% ошибок в программе вылетали наверх паниками
Значит, скорее всего, нужно фиксить код, чтобы паник не было. А не пытаться как-то поладить с паниками.
Так они рукотворные были, через panic!(). Мне тут скорее интересно мнение сообщество, насколько это нормальная практика
Нормальная, например, если реализовать свое число и поделить на нуль. Вот тогда вполне себе нормальная. Так что зависит от случая. Но Result/Option всё же предпочтительнее
https://doc.rust-lang.org/stable/std/sync/struct.Mutex.html
А в чем проблема мьютекса?
в описании он становится отравленным в случае паники во время того, как держишь лок
Обсуждают сегодня