Why does the Rust compiler not convert from a library error to my error using the From trait?
Given this crate referencing an error from another crate, I would normally write a From
implementation to convert types.
use xladd::variant::{Variant, XLAddError};
use failure::Fail;
use std::convert::TryInto;
use std::convert::From;
use std::error::Error;
#[derive(Debug, Fail)]
enum AARCError {
#[fail(display = "F64 Conversion failure")]
ExcelF64ConversionError,
#[fail(display = "Bool Conversion failure")]
ExcelBoolConversionError,
#[fail(display = "Conversion failure")]
ExcelStrConversionError,
}
impl From<XLAddError> for AARCError {
fn from(err: XLAddError) -> Self {
AARCError::ExcelF64ConversionError // Test for now
}
}
pub fn normalize(array: Variant, min: Variant, max: Variant, scale: Variant) -> Result<Variant, AARCError> {
let min: f64 = min.try_into().map_err(|e| AARCError::from(e))?;
Ok(Variant::from_str("foo"))
}
But in this case I get an error:
error[E0277]: the trait bound `basic_stats::AARCError: std::convert::From<!>` is not satisfied
--> srcbasic_stats.rs:24:48
|
24 | let min: f64 = min.try_into().map_err(|e| AARCError::from(e))?;
| ^^^^^^^^^^^^^^^ the trait `std::convert::From<!>` is not implemented for `basic_stats::AARCError`
|
= help: the following implementations were found:
<basic_stats::AARCError as std::convert::From<xladd::variant::XLAddError>>
= note: required by `std::convert::From::from`
I don't understand what the From<!>
trait is and trying to implement something like that gives an error for unnamed types.
What should I be doing to enable Rust to convert the external crate's errors to my ones?
error-handling rust
add a comment |
Given this crate referencing an error from another crate, I would normally write a From
implementation to convert types.
use xladd::variant::{Variant, XLAddError};
use failure::Fail;
use std::convert::TryInto;
use std::convert::From;
use std::error::Error;
#[derive(Debug, Fail)]
enum AARCError {
#[fail(display = "F64 Conversion failure")]
ExcelF64ConversionError,
#[fail(display = "Bool Conversion failure")]
ExcelBoolConversionError,
#[fail(display = "Conversion failure")]
ExcelStrConversionError,
}
impl From<XLAddError> for AARCError {
fn from(err: XLAddError) -> Self {
AARCError::ExcelF64ConversionError // Test for now
}
}
pub fn normalize(array: Variant, min: Variant, max: Variant, scale: Variant) -> Result<Variant, AARCError> {
let min: f64 = min.try_into().map_err(|e| AARCError::from(e))?;
Ok(Variant::from_str("foo"))
}
But in this case I get an error:
error[E0277]: the trait bound `basic_stats::AARCError: std::convert::From<!>` is not satisfied
--> srcbasic_stats.rs:24:48
|
24 | let min: f64 = min.try_into().map_err(|e| AARCError::from(e))?;
| ^^^^^^^^^^^^^^^ the trait `std::convert::From<!>` is not implemented for `basic_stats::AARCError`
|
= help: the following implementations were found:
<basic_stats::AARCError as std::convert::From<xladd::variant::XLAddError>>
= note: required by `std::convert::From::from`
I don't understand what the From<!>
trait is and trying to implement something like that gives an error for unnamed types.
What should I be doing to enable Rust to convert the external crate's errors to my ones?
error-handling rust
What are the crates (and versions thereof) that you are using? Please take a look at how to create a Minimal, Complete, and Verifiable example and edit your question so that people can easily run your code and see the same results.
– E4_net_or_something_like_that
Nov 25 '18 at 2:03
add a comment |
Given this crate referencing an error from another crate, I would normally write a From
implementation to convert types.
use xladd::variant::{Variant, XLAddError};
use failure::Fail;
use std::convert::TryInto;
use std::convert::From;
use std::error::Error;
#[derive(Debug, Fail)]
enum AARCError {
#[fail(display = "F64 Conversion failure")]
ExcelF64ConversionError,
#[fail(display = "Bool Conversion failure")]
ExcelBoolConversionError,
#[fail(display = "Conversion failure")]
ExcelStrConversionError,
}
impl From<XLAddError> for AARCError {
fn from(err: XLAddError) -> Self {
AARCError::ExcelF64ConversionError // Test for now
}
}
pub fn normalize(array: Variant, min: Variant, max: Variant, scale: Variant) -> Result<Variant, AARCError> {
let min: f64 = min.try_into().map_err(|e| AARCError::from(e))?;
Ok(Variant::from_str("foo"))
}
But in this case I get an error:
error[E0277]: the trait bound `basic_stats::AARCError: std::convert::From<!>` is not satisfied
--> srcbasic_stats.rs:24:48
|
24 | let min: f64 = min.try_into().map_err(|e| AARCError::from(e))?;
| ^^^^^^^^^^^^^^^ the trait `std::convert::From<!>` is not implemented for `basic_stats::AARCError`
|
= help: the following implementations were found:
<basic_stats::AARCError as std::convert::From<xladd::variant::XLAddError>>
= note: required by `std::convert::From::from`
I don't understand what the From<!>
trait is and trying to implement something like that gives an error for unnamed types.
What should I be doing to enable Rust to convert the external crate's errors to my ones?
error-handling rust
Given this crate referencing an error from another crate, I would normally write a From
implementation to convert types.
use xladd::variant::{Variant, XLAddError};
use failure::Fail;
use std::convert::TryInto;
use std::convert::From;
use std::error::Error;
#[derive(Debug, Fail)]
enum AARCError {
#[fail(display = "F64 Conversion failure")]
ExcelF64ConversionError,
#[fail(display = "Bool Conversion failure")]
ExcelBoolConversionError,
#[fail(display = "Conversion failure")]
ExcelStrConversionError,
}
impl From<XLAddError> for AARCError {
fn from(err: XLAddError) -> Self {
AARCError::ExcelF64ConversionError // Test for now
}
}
pub fn normalize(array: Variant, min: Variant, max: Variant, scale: Variant) -> Result<Variant, AARCError> {
let min: f64 = min.try_into().map_err(|e| AARCError::from(e))?;
Ok(Variant::from_str("foo"))
}
But in this case I get an error:
error[E0277]: the trait bound `basic_stats::AARCError: std::convert::From<!>` is not satisfied
--> srcbasic_stats.rs:24:48
|
24 | let min: f64 = min.try_into().map_err(|e| AARCError::from(e))?;
| ^^^^^^^^^^^^^^^ the trait `std::convert::From<!>` is not implemented for `basic_stats::AARCError`
|
= help: the following implementations were found:
<basic_stats::AARCError as std::convert::From<xladd::variant::XLAddError>>
= note: required by `std::convert::From::from`
I don't understand what the From<!>
trait is and trying to implement something like that gives an error for unnamed types.
What should I be doing to enable Rust to convert the external crate's errors to my ones?
error-handling rust
error-handling rust
edited Nov 25 '18 at 2:52
E4_net_or_something_like_that
16.7k74388
16.7k74388
asked Nov 24 '18 at 21:47
RonnieRonnie
1,30011028
1,30011028
What are the crates (and versions thereof) that you are using? Please take a look at how to create a Minimal, Complete, and Verifiable example and edit your question so that people can easily run your code and see the same results.
– E4_net_or_something_like_that
Nov 25 '18 at 2:03
add a comment |
What are the crates (and versions thereof) that you are using? Please take a look at how to create a Minimal, Complete, and Verifiable example and edit your question so that people can easily run your code and see the same results.
– E4_net_or_something_like_that
Nov 25 '18 at 2:03
What are the crates (and versions thereof) that you are using? Please take a look at how to create a Minimal, Complete, and Verifiable example and edit your question so that people can easily run your code and see the same results.
– E4_net_or_something_like_that
Nov 25 '18 at 2:03
What are the crates (and versions thereof) that you are using? Please take a look at how to create a Minimal, Complete, and Verifiable example and edit your question so that people can easily run your code and see the same results.
– E4_net_or_something_like_that
Nov 25 '18 at 2:03
add a comment |
1 Answer
1
active
oldest
votes
I don't understand what the
From<!>
trait is and trying to implement something like that gives an error for unnamed types.
!
is the "never" or uninhabited type; the type that has no possible values.
If a Result
has !
for its error type, that means the operation cannot fail. It is impossible to convert from it to some other error type, because an error value cannot exist in the first place.
The never type is currently an experimental feature, requiring a nightly build of Rust. As such, it likely has a few rough edges, and it isn't as ergonomic as it could be. For example, I would expect the final feature to provide a blanket From<T>
implementation for all types that implement TryFrom<T>
with associated type Error = !
. It should be made easy to not have to handle the error that can't happen.
To fix your immediate problem, you can map that error to unreachable!()
. The only issue with that approach is forwards-compatibility - if the third party crate later introduces a reachable error then your code would have an unhandled error, and no compile-time error to protect you. That's probably a part of why !
is not yet stabilised.
1
I believe this is only available in nightly as well, for reference.
– jhpratt
Nov 25 '18 at 2:56
@jhpratt I think OP must be using nightly to have gotten this far... I will add a note though.
– E4_net_or_something_like_that
Nov 25 '18 at 3:09
1
I believe that as well. I'm just stating that for others that may come across it.
– jhpratt
Nov 25 '18 at 5:40
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53462653%2fwhy-does-the-rust-compiler-not-convert-from-a-library-error-to-my-error-using-th%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I don't understand what the
From<!>
trait is and trying to implement something like that gives an error for unnamed types.
!
is the "never" or uninhabited type; the type that has no possible values.
If a Result
has !
for its error type, that means the operation cannot fail. It is impossible to convert from it to some other error type, because an error value cannot exist in the first place.
The never type is currently an experimental feature, requiring a nightly build of Rust. As such, it likely has a few rough edges, and it isn't as ergonomic as it could be. For example, I would expect the final feature to provide a blanket From<T>
implementation for all types that implement TryFrom<T>
with associated type Error = !
. It should be made easy to not have to handle the error that can't happen.
To fix your immediate problem, you can map that error to unreachable!()
. The only issue with that approach is forwards-compatibility - if the third party crate later introduces a reachable error then your code would have an unhandled error, and no compile-time error to protect you. That's probably a part of why !
is not yet stabilised.
1
I believe this is only available in nightly as well, for reference.
– jhpratt
Nov 25 '18 at 2:56
@jhpratt I think OP must be using nightly to have gotten this far... I will add a note though.
– E4_net_or_something_like_that
Nov 25 '18 at 3:09
1
I believe that as well. I'm just stating that for others that may come across it.
– jhpratt
Nov 25 '18 at 5:40
add a comment |
I don't understand what the
From<!>
trait is and trying to implement something like that gives an error for unnamed types.
!
is the "never" or uninhabited type; the type that has no possible values.
If a Result
has !
for its error type, that means the operation cannot fail. It is impossible to convert from it to some other error type, because an error value cannot exist in the first place.
The never type is currently an experimental feature, requiring a nightly build of Rust. As such, it likely has a few rough edges, and it isn't as ergonomic as it could be. For example, I would expect the final feature to provide a blanket From<T>
implementation for all types that implement TryFrom<T>
with associated type Error = !
. It should be made easy to not have to handle the error that can't happen.
To fix your immediate problem, you can map that error to unreachable!()
. The only issue with that approach is forwards-compatibility - if the third party crate later introduces a reachable error then your code would have an unhandled error, and no compile-time error to protect you. That's probably a part of why !
is not yet stabilised.
1
I believe this is only available in nightly as well, for reference.
– jhpratt
Nov 25 '18 at 2:56
@jhpratt I think OP must be using nightly to have gotten this far... I will add a note though.
– E4_net_or_something_like_that
Nov 25 '18 at 3:09
1
I believe that as well. I'm just stating that for others that may come across it.
– jhpratt
Nov 25 '18 at 5:40
add a comment |
I don't understand what the
From<!>
trait is and trying to implement something like that gives an error for unnamed types.
!
is the "never" or uninhabited type; the type that has no possible values.
If a Result
has !
for its error type, that means the operation cannot fail. It is impossible to convert from it to some other error type, because an error value cannot exist in the first place.
The never type is currently an experimental feature, requiring a nightly build of Rust. As such, it likely has a few rough edges, and it isn't as ergonomic as it could be. For example, I would expect the final feature to provide a blanket From<T>
implementation for all types that implement TryFrom<T>
with associated type Error = !
. It should be made easy to not have to handle the error that can't happen.
To fix your immediate problem, you can map that error to unreachable!()
. The only issue with that approach is forwards-compatibility - if the third party crate later introduces a reachable error then your code would have an unhandled error, and no compile-time error to protect you. That's probably a part of why !
is not yet stabilised.
I don't understand what the
From<!>
trait is and trying to implement something like that gives an error for unnamed types.
!
is the "never" or uninhabited type; the type that has no possible values.
If a Result
has !
for its error type, that means the operation cannot fail. It is impossible to convert from it to some other error type, because an error value cannot exist in the first place.
The never type is currently an experimental feature, requiring a nightly build of Rust. As such, it likely has a few rough edges, and it isn't as ergonomic as it could be. For example, I would expect the final feature to provide a blanket From<T>
implementation for all types that implement TryFrom<T>
with associated type Error = !
. It should be made easy to not have to handle the error that can't happen.
To fix your immediate problem, you can map that error to unreachable!()
. The only issue with that approach is forwards-compatibility - if the third party crate later introduces a reachable error then your code would have an unhandled error, and no compile-time error to protect you. That's probably a part of why !
is not yet stabilised.
edited Nov 25 '18 at 3:09
answered Nov 25 '18 at 2:50
E4_net_or_something_like_thatE4_net_or_something_like_that
16.7k74388
16.7k74388
1
I believe this is only available in nightly as well, for reference.
– jhpratt
Nov 25 '18 at 2:56
@jhpratt I think OP must be using nightly to have gotten this far... I will add a note though.
– E4_net_or_something_like_that
Nov 25 '18 at 3:09
1
I believe that as well. I'm just stating that for others that may come across it.
– jhpratt
Nov 25 '18 at 5:40
add a comment |
1
I believe this is only available in nightly as well, for reference.
– jhpratt
Nov 25 '18 at 2:56
@jhpratt I think OP must be using nightly to have gotten this far... I will add a note though.
– E4_net_or_something_like_that
Nov 25 '18 at 3:09
1
I believe that as well. I'm just stating that for others that may come across it.
– jhpratt
Nov 25 '18 at 5:40
1
1
I believe this is only available in nightly as well, for reference.
– jhpratt
Nov 25 '18 at 2:56
I believe this is only available in nightly as well, for reference.
– jhpratt
Nov 25 '18 at 2:56
@jhpratt I think OP must be using nightly to have gotten this far... I will add a note though.
– E4_net_or_something_like_that
Nov 25 '18 at 3:09
@jhpratt I think OP must be using nightly to have gotten this far... I will add a note though.
– E4_net_or_something_like_that
Nov 25 '18 at 3:09
1
1
I believe that as well. I'm just stating that for others that may come across it.
– jhpratt
Nov 25 '18 at 5:40
I believe that as well. I'm just stating that for others that may come across it.
– jhpratt
Nov 25 '18 at 5:40
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53462653%2fwhy-does-the-rust-compiler-not-convert-from-a-library-error-to-my-error-using-th%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
What are the crates (and versions thereof) that you are using? Please take a look at how to create a Minimal, Complete, and Verifiable example and edit your question so that people can easily run your code and see the same results.
– E4_net_or_something_like_that
Nov 25 '18 at 2:03