# Aleksey Kladov - Study of Std::io::Error (Highlights)  ## Metadata **Cover**:: https://readwise-assets.s3.amazonaws.com/static/images/article3.5c705a01b476.png **Source**:: #from/readwise **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Aleksey Kladov]] **Full Title**:: Study of Std::io::Error **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **URL**:: [matklad.github.io](https://matklad.github.io//2020/10/15/study-of-std-io-error.html) **Host**:: [[matklad.github.io]] **Highlighted**:: [[2020-11-15]] **Created**:: [[2022-09-26]] ## Highlights - the main question to ask is “how the error will be used?” - The error is handled programmatically. - The error is propagated and displayed to the user. - A common anti-pattern for implementing the first case is to define a kitchen-sink enum - Kitchen sink errors pack dissimilar failure modes into one type. But, if failure modes vary widely, it probably isn’t reasonable to handle them! This is an indication that the situation looks more like the case two. - Generic `new` function delegates to monomorphic `_new` function. This improves compile time, as less code needs to be duplicated during monomorphization. - encapsulates its internal representation and optimizes it by boxing large enum variant, - provides a convenient way to handle error based on category via `ErrorKind` pattern, - fully exposes underlying OS error, if any. - can transparently wrap any other error type. - The number one problem with `std::io::Error` is that, when a file-system operation fails, you don’t know which path it has failed for! - `io::Error` doesn’t carry a backtrace. - The other problem is that `std::io::Error` is not as efficient as it could be: - Its size is pretty big: - [`GlobalAlloc`](https://doc.rust-lang.org/stable/std/alloc/trait.GlobalAlloc.html) exist