starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #318] Heavy-weight errors #144

New issue

Closed

opened 2026-03-07 22:26:51 +03:00 by kerem · 6 comments

kerem commented

2026-03-07 22:26:51 +03:00

Owner

Originally created by @vorner on GitHub (Dec 17, 2017).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/318

Hello

I believe it makes little sense to mandate that every error in that crate has a backtrace on it, eg: https://docs.rs/trust-dns-proto/0.2.0/trust_dns_proto/error/struct.ProtoError.html.

I think so for two reasons:

Failing to parse some data that arrived over network has no reason to contain a backtrace.
The generation of a backtrace isn't cheap and this could be misused by an external entity to eg. DOS the server.

Originally created by @vorner on GitHub (Dec 17, 2017). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/318 Hello I believe it makes little sense to mandate that every error in that crate has a backtrace on it, eg: https://docs.rs/trust-dns-proto/0.2.0/trust_dns_proto/error/struct.ProtoError.html. I think so for two reasons: * Failing to parse some data that arrived over network has no reason to contain a backtrace. * The generation of a backtrace isn't cheap and this could be misused by an external entity to eg. DOS the server.

kerem

2026-03-07 22:26:51 +03:00

closed this issue
added the
crate:all

cleanup
labels

kerem commented

2026-03-07 22:27:07 +03:00

Author

Owner

@bluejekyll commented on GitHub (Dec 17, 2017):

There is also a discussion I've had on switch to the Failure traits and away from error-chain. I'm open to reducing the backtrace usage, though it is useful for debugging issues. Perhaps we should make it a feature that is on or off by default.

@bluejekyll commented on GitHub (Dec 17, 2017): There is also a discussion I've had on switch to the `Failure` traits and away from `error-chain`. I'm open to reducing the backtrace usage, though it is useful for debugging issues. Perhaps we should make it a feature that is on or off by default.

kerem commented

2026-03-07 22:27:13 +03:00

Author

Owner

@vorner commented on GitHub (Dec 18, 2017):

Well, the Failure could work. The backtrace is optional there (the error is free to not provide it) and the Error there does a snapshot of the stack, but resolves the backtrace only if it gets actually produced, so even that is much more light weight.

@vorner commented on GitHub (Dec 18, 2017): Well, the Failure could work. The backtrace is optional there (the error is free to not provide it) and the `Error` there does a snapshot of the stack, but resolves the backtrace only if it gets actually produced, so even that is much more light weight.

kerem commented

2026-03-07 22:27:18 +03:00

Author

Owner

@DemiMarie commented on GitHub (Feb 18, 2018):

I’ll take this for a school project.

@DemiMarie commented on GitHub (Feb 18, 2018): I’ll take this for a school project.

kerem commented

2026-03-07 22:27:23 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 18, 2018):

#326 is the issue to migrate to failures.

I implemented my first failure resently. It may not be an obvious transition in some cases. Definitely reach out for help, you’re going to run into some old ugly code in spots.

@bluejekyll commented on GitHub (Feb 18, 2018): #326 is the issue to migrate to failures. I implemented my first failure resently. It may not be an obvious transition in some cases. Definitely reach out for help, you’re going to run into some old ugly code in spots.

kerem commented

2026-03-07 22:27:28 +03:00

Author

Owner

@briansmith commented on GitHub (Apr 23, 2018):

This was fixed in PR #416.

@briansmith commented on GitHub (Apr 23, 2018): This was fixed in PR #416.

kerem commented

2026-03-07 22:27:33 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 12, 2018):