Comments (8)
Yes, would be better to return a Result<Option<PathBuf>>
as debug info not being available isn't a fatal error.
from locate-dwarf.
I'd be willing to change this crate to use
thiserror
if you are open to it?
I had originally used failure
, but thiserror
is absolutely more useful for library crates.
from locate-dwarf.
I had originally used failure, but thiserror is absolutely more useful for library crates.
That is actually a myth in most cases. The way thiserror
is usually abused people put all the possible errors that any code path in a crate could have in an enum and then return it from everywhere. The main argument for thiserror
is handling all possible errors and have the compiler check that all cases are handled. Which is a bad argument for one because not all errors are possible in every code path and the wrapping and rewrapping of errors (each library has at least an Io variant) actually makes it harder, and most ways of handling errors involve one of retrying/logging/aborting. And there are a whole host of other reasons why that "rule of thumb" brainlessly applied yields worse results than just using anyhow. You need to capture your backtraces manually which absolutely no one does, it's slower, etc.
And in this case the library is so trivial that an Option
is a much better solution anyway. However where thiserror
shines is in conveniently deriving Display
.
EDIT: sorry if it came of as a little aggressive, I just don't like "wisdom of the crowd" being justified by it's "the wisdom of the crowd". I'm happy to hear why thiserror is perfectly suited for this crate.
from locate-dwarf.
sorry if it came of as a little aggressive, I just don't like "wisdom of the crowd" being justified by it's "the wisdom of the crowd". I'm happy to hear why thiserror is perfectly suited for this crate.
No worries, I understand thiserror
makes it super easy for someone to just add in all possible errors. That's not what I'm suggesting. I just like thiserror
for two reasons (one of which you mentioned).
- It derives
Display
for you - It makes using
source
very easy (ok... this may be exactly proving your point, but in some cases it's very useful)
And in this case the library is so trivial that an Option is a much better solution anyway.
I started down this path but there are a couple errors that are explicitly handled in this crate. I believe they are ok to switch to Option
but would love feedback on that decision. Specifically they are:
- The given build-id to
locate_debug_build_id
is too short. - The parameter
path
passed intolocate_gnu_debuglink
can not becanonicalize
'd or does not have a parent. - The
object::Object
variable in locate debug symbols has some error when attempting to readmach_uuid
,build_id
, orgnu_debuglink
. - Rust can't convert the debuglink path to a real path.
For case 1, if the buildid is less than 2 bytes we should return None
because it wouldn't be in a .build-id folder anyway.
For case 2, we can return None
since a path that did not have a parent would not work for all those searches anyway.
For case 3, these will all occur if the passed in object
was corrupted in some way. It might be nice for the user to know that but we could also say " if that data is corrupted, we can't find the dwarf anyway
For case 4, if the path is invalid UTF-8, we won't be able to find the dwarf anyway.
from locate-dwarf.
I'd suggest returning an error if there is corruption or a transient error and None
if it isn't found. A transient error would be an io error that could just be ?
. For the corruption case it may be worth enumerating the cases like this:
#[derive(Debug, Error)]
pub enum CorruptObject {
#[error("build id is too short")]
BuildIdTooShort,
...
}
This way if someone really wants to handle the corrupt/transient errors differently they can use downcast_ref::<CorruptObject>
or downcast_ref::<std::io::Error>
and backtraces are still captured (as the return type would be an anyhow::Result
).
from locate-dwarf.
I've created a PR #49 that partially completes this work. It adds in the Option
to the success case of the returned path. But it does not include the custom error object. I'm working on that next.
from locate-dwarf.
FWIW, having just run into a similar issue attempting to use this crate for a small tool, I can say that at a bare minimum whatever error type this crate returns needs to be exported as part of the public API. At present it's not possible to refer to locate_dwarf::Error
.
A bit late, but in re:
I had originally used failure, but thiserror is absolutely more useful for library crates.
That is actually a myth in most cases
I simply meant "failure
is unmaintained, thiserror
is under active development".
To the original point of this issue: anyhow
seems intended for application usage, not library usage, for the "roll all errors up into a single error type" use case. I'm not particularly hung up on this.
from locate-dwarf.
Not really that bothered since I'm not currently using locate-dwarf. But you're not going to convince me that thiserror is better for library crates than anyhow for various reasons I mentioned. It may be that in some cases it's a better fit when done correctly. But if you're just wrapping every error from every dependency in a new enum it's not the case. And please make sure that at least the backtrace is captured and unwrapping an error actually displays were the error was constructed and not where it was unwrapped.
from locate-dwarf.
Related Issues (8)
- Notes... HOT 5
- Replace usage of CoreFoundation-sys with core-foundation HOT 2
- Bring this crate up to a releaseable state HOT 4
- Finding dSYM file on macOS can be very slow HOT 3
- Migrate CI to GitHub Actions HOT 1
- Support for PE -> PDB lookup HOT 4
- Panic when used on binaries that are in a "target" directory without deps / examples subdirectories
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from locate-dwarf.