Planning Errors about nemo HOT 5 CLOSED

That's now getting a bit more into design specifics: a VectorColumn, e.g., will also panic if you have only five elements and call get(23). We might consider changing the Column trait to have a get(usize) -> Option<T> and a get_unchecked(usize) -> T to handle that, as std::vec::Vec does.

from nemo.

Having a CONTRIBUTING.md is surely a good idea, and also a good place to put down such decisions.

from nemo.

My views on this are as follows:

• any error that potentially traverses the crate boundary (i.e., anything that does not get handled by the crate itself, or that panic!s) is a crate::error::error,
• an error that is handled by the same module can be a simple struct, or an enum if there are multiple variants,
• errors exposed to the rest of the crate have a corresponding variant in crate::error::error, which can be #[from] a module-level error enum,
• errors from the standard library have a #[error(transparent)] variant in crate::error::error,
• panic! (and expect(), assert!, etc.) is fine for situations that should not occur, e.g., if there is some invariant that makes the situation impossible, or where graceful recovery is impossible, but not otherwise, and
• unwrap() should (almost?) always be expect() instead

from nemo.

My views on this are as follows:

• any error that potentially traverses the crate boundary (i.e., anything that does not get handled by the crate itself, or that panic!s) is a crate::error::error,
• an error that is handled by the same module can be a simple struct, or an enum if there are multiple variants,
• errors exposed to the rest of the crate have a corresponding variant in crate::error::error, which can be #[from] a module-level error enum,
• errors from the standard library have a #error(transparent) variant in crate::error::error,
• panic! (and expect(), assert!, etc.) is fine for situations that should not occur, e.g., if there is some invariant that makes the situation impossible, or where graceful recovery is impossible, but not otherwise, and
• unwrap() should (almost?) always be expect() instead

My point of view is quite the same. Though I don't think that we have cases where we shall outright panic. Just wrapping the issue into an error and let it traverse to the top level sounds much more recoverable. (Lets say in the rle case - an error could allow to just use another column which works, while panic makes it outright impossible to react)

Note 'sanity' checks, like the one in rle are fine though.

from nemo.

Another thing we still need to decide is to where we are listing all these design decisions.

I think a CONTRIBUTING.md would be the natural way of collecting all conventions and strategies for implementing things in this project.

How are your positions on this?

from nemo.