into_rust() — скринкасты по Rust. Доступно видео с RustConf 2016.

но на данный момент, так делать не принято. И с таким использованием я не сталкивался.

С unwrap() ты не сталкивался??? Но это же очевидное враньё!

Аргументов снова нет?

У тебя нет аргументов, ты же к цитатам авторов цепляешься со своим мнением.

Процитируй. Или только щёки надувать способен?

User code that uses C++ keywords like throw, try, and catch will produce errors even if the user code has included libstdc++ headers and is using constructs like basic_iostream. Even though the standard library has been transformed, user code may need modification. User code that attempts or expects to do error checking on standard library components compiled with exception handling disabled should be evaluated and potentially made conditional.

Началось то с того, что:

// Тут тоже может вылететь исключение E и это не нормально, но разработчик провтыкал.

Я понимаю, если разработчик не прочитает документацию и вызовет функцию, выбрасывающую исключение. Но если он знает, что тут ничего вылетать не должно, и тем не менее меняет сигнатуру process() и пишет try!() вместо unwrap_or, это уже как-то менее понятно.

Я воспринял пример DarkEld3r явно иначе, чем вы.

В случае с checked exception если мы имеем:

ret_type a() throw E {...}
ret_type b() throw Y {...}
ret_type foo() throw E {
  auto v = a();
  b();
}

Однако, если мы имеем:

ret_type a() throw E {...}
ret_type b() throw E {...}
ret_type foo() throw E {
  auto v = a();
  b();
}

Аналогично, в Rust-е мы можем имеет что-то вроде:

fn a() -> Result<R, E> {...}
fn b() -> Result<R, E> {...}
fn foo() -> Result<R, E> {
  let v = try!(a());
  let v2 = try!(b());
  ..
}

Извиняюсь, не сообразил, что в примере использовался псевдо-С++ с checked-exceptions, а не throw-спецификации из какой-то версии С++.

Внутри чего?

Внутри макроса. Там вы можете вызывать методы, которые могут бросить панику.

Да и в Rust-е может быть Result<SomeType, Error>, где за Error прячется целая куча типов, реализующих интерфейс Error.

Во-первых, Result<SomeType, Box<Error>>. Во-вторых, непонятно, зачем кому-то может понадобиться такое делать.

Во-первых, Result<SomeType, Box<Error>>. Во-вторых, непонятно, зачем кому-то может понадобиться такое делать.

https://users.rust-lang.org/t/announcing-error-chain-a-library-for-consistent...

Во-вторых, непонятно, зачем кому-то может понадобиться такое делать.

Согласен, хороший вопрос.

error-chain

Это же просто генерилка enum'ов, включающих разные ошибки. Не вижу, как оно относится к упомянутой eao197 проблеме.

Хех, а я вот вожусь с подключением vectored execeptions handling, чтобы задавить исключение, которое забыли подавить разработчики GPU-based validation.

Не уверен, что это можно считать аргументом. (:

Или думаешь, что с паникой такого не могло бы быть?

Так ведь это же прямой путь к паникам, не?

Да, но это устраивает. В общем, это (вероятно частный) случай когда логика паник очень удачно ложиться: почти все проблемы надо обрабатывать, но некоторые считаются «совсем фатальными».

С unwrap() ты не сталкивался??? Но это же очевидное враньё!

Ты издеваешься? Не сталкивался с применением паники «вместо исключений». То есть, с построением логики на перехвате паники и, тем более, на перехвате паники с разными вариантами обработки, в зависимости от типа.

У тебя нет аргументов, ты же к цитатам авторов цепляешься со своим мнением.

Давай ты нормально претензии озвучишь. Пока что это похоже на какой-то абсурд: я не спорю с тем, что «паника реализована как исключения», но только при panic=unwind, что не является единственным доступным вариантом.

User code that uses C++ keywords like throw, try, and catch will produce errors

Ок, я был не прав.

Тем не менее, исключение может быть выброшено из библиотеки.

Да это и не аргумент был. К слову пришлось. С документацией к SEH, кстати, какая-то ерунда. На MSDN ничего полезного кроме бесполезных __try, __except поиском не находится. Гугл находит какую-то древнюю статью, предлагающую работать через fs:[0]. Я уже и растовским инлайн ассеблером успел побаловаться (удобно), пока нормальное API нашёл.

Ладно. Оффтопик.

У нее внутри Box<StdError>.

У неё внутри сгенеренный ErrorKind. Box<StdError> - это предыдущая ошибка.

У нее внутри Box<StdError>.

Box<StdError> - это предыдущая ошибка.

Да. Это и является ответом на вопрос «зачем кому-то может понадобиться такое делать».

Это и является ответом на вопрос «зачем кому-то может понадобиться такое делать».

Речь была о:

«В таких условиях вместо исключений запросто можно брать Result<Type, Error>, а затем плодить и возвращать кучу разных Error-ов, о которых конечный пользователь может даже и не подозревать.»

В error-chain ничего не плодят и не возвращают. Вернее, там плодят варианты ErrorKind'а и мапят в них чужие ошибки, а речь была о возвращении из функции разных ошибок в виде Box<Error>.

В error-chain ничего не плодят и не возвращают. Вернее, там плодят варианты ErrorKind'а и мапят в них чужие ошибки, а речь была о возвращении из функции разных ошибок в виде Box<Error>.

В error-chain именно возвращают чужие ошибки в виде Box<Error>.

http://rust-lang-nursery.github.io/rustup.rs/error_chain/index.html#chaining-...

" If the Result is an Err then chain_err evaluates the closure, which returns some type that can be converted to ErrorKind, boxes the original error to store as the cause, then returns a new error containing the original error"

Больше никак чейнинг и не реализовать.

К Go равнодушен, но дубина из дуба, как раз, прекрасна и функциональна :)

а для embedded...

а для embedded, по большей части, это как раз и есть состояние «всё, приехали» и срабатывает паника. Результат которой, обычно, для дебаг сборок - диагностическая информация, а для продакшена - ребут («быстро поднятое, упавшим не считается»).

Для определенных задач - да, но если этим пользоваться как универсальным инструментом...

Ну почему? Можно и муху у себя на лбу прихлопнуть.

Мне, как пользователю, твои трейсы не нужны. Я хочу продолжать работать с программой. Мне без разницы, будет сегфолт или сообщение. В обоих случаях я скажу, что разработчик идиот.

Мне, как пользователю, твои трейсы не нужны.

Они тебе понадобятся, если придётся вступить в контакт с техподдержкой/разработчиком.

В обоих случаях я скажу, что разработчик идиот.

Людям свойственно ошибаться. Идиоты - те, кто этого не понимает.

Поэтому отключение телеметрии делают незаметной галочкой, чтобы кроме ругани получить от пользователя что-нибудь полезное.

Сишники послали растовцев c их натянутыми проблемами, так теперь они стали заказывать статьи вида Rust vs Java?? Rust 1.7 (комментарий)

Даааа, это прям мечта джависта, язык почти такой же производительности (и жруший столько же памяти), но при этом теперь тебе на халяву нужно страдать с лайфтаймами, с компилятором и гибридно-испорченным синтаксисом из ФП Причем там даже не завезли инкапсуляцию (сколько веселья то для промышленного кода)?

Это успех я считаю

Причем там даже не завезли инкапсуляцию

Что, опять?