Plume/Plume

Avoid panics #392

Merged

elegaanz merged 8 commits from result into master

2018-12-29 08:36:07 +00:00

elegaanz commented

2018-12-26 19:11:52 +00:00

(Migrated from github.com)

Use Result as much as possible
Display errors instead of panicking

TODO (maybe in another PR? this one is already quite big):

Find a way to merge Ructe/ErrorPage types, so that we can have routes returning Result<X, ErrorPage> instead of panicking when we have an Error
Display more details about the error, to make it easier to debug

(sorry, this isn't going to be fun to review, the diff is huge, but it is always the same changes)

- Use `Result` as much as possible - Display errors instead of panicking TODO (maybe in another PR? this one is already quite big): - Find a way to merge Ructe/ErrorPage types, so that we can have routes returning `Result<X, ErrorPage>` instead of panicking when we have an `Error` - Display more details about the error, to make it easier to debug (sorry, this isn't going to be fun to review, the diff is huge, but it is always the same changes)

trinity-1686a commented

2018-12-26 21:01:12 +00:00

Owner

(sorry, this isn't going to be fun to review, the diff is huge, but it is always the same changes)

I guess it wasn't fun to write either

> (sorry, this isn't going to be fun to review, the diff is huge, but it is always the same changes) I guess it wasn't fun to write either

igalic (Migrated from github.com) reviewed 2018-12-26 23:30:20 +00:00

igalic (Migrated from github.com) left a comment

first pass, not done yet

first pass, not done yet

plume-common/src/activity_pub/mod.rs

					
				@ -122,3 +122,3 @@

				    act["@context"] = context();

				    let signed = act.sign(sender);

				    let signed = act.sign(sender).expect("activity_pub::broadcast: signature error");

igalic (Migrated from github.com) commented

2018-12-26 22:41:03 +00:00

i thought we're trying to avoid panics?

i thought we're trying to avoid panics?

plume-common/src/activity_pub/request.rs

					
				@ -107,3 +107,3 @@

				pub fn signature<S: Signer>(signer: &S, headers: &HeaderMap) -> HeaderValue {

				pub fn signature<S: Signer>(signer: &S, headers: &HeaderMap) -> Result<HeaderValue, ()> {

				    let signed_string = headers

igalic (Migrated from github.com) commented

2018-12-26 22:42:59 +00:00

can you briefly explain this return signature?
maybe then I'll also understand the above expect()

can you briefly explain this return signature? maybe then I'll also understand the above `expect()`

plume-models/src/blogs.rs

					
				@ -214,0 +170,4 @@

				                    // We don't really care about all the following for remote instances

				                    long_description: SafeString::new(""),

				                    short_description: SafeString::new(""),

				                    default_license: String::new(),

igalic (Migrated from github.com) commented

2018-12-26 22:47:42 +00:00

wow! that's some really nice refactoring! 👍

wow! that's some really nice refactoring! 👍

plume-models/src/blogs.rs

igalic (Migrated from github.com) commented

2018-12-26 22:53:51 +00:00

so, it's ok, or desired, that tests panic, right?

so, it's ok, or desired, that tests panic, right?

plume-models/src/comments.rs

igalic (Migrated from github.com) commented

2018-12-26 23:10:04 +00:00

neat!

neat!

plume-models/src/comments.rs

igalic (Migrated from github.com) commented

2018-12-26 23:15:28 +00:00

https://doc.rust-lang.org/std/result/enum.Result.html#method.map_err i read the doc, but still don't understand what this does

https://doc.rust-lang.org/std/result/enum.Result.html#method.map_err i read the doc, but still don't understand what this does

trinity-1686a reviewed 2018-12-26 23:39:06 +00:00

plume-models/src/comments.rs

trinity-1686a commented

2018-12-26 23:39:06 +00:00

Owner

I you understand map, this is basically the same thing, but for Err(_) instead of Ok(_). And passing Error::from is the equivalent to |e| e.from()
This is just mapping an error type to another

I you understand `map`, this is basically the same thing, but for `Err(_)` instead of `Ok(_)`. And passing `Error::from` is the equivalent to `|e| e.from()` This is just mapping an error type to another

elegaanz (Migrated from github.com) reviewed 2018-12-27 00:21:45 +00:00

plume-common/src/activity_pub/mod.rs

					
				@ -122,3 +122,3 @@

				    act["@context"] = context();

				    let signed = act.sign(sender);

				    let signed = act.sign(sender).expect("activity_pub::broadcast: signature error");

elegaanz (Migrated from github.com) commented

2018-12-27 00:21:45 +00:00

Ahah, right… It actually doesn't add a panic, we just panic "outside" of the function instead of "inside" because it wouldn't make much sense to return a Result from broadcast as it is always the main function of its thread.

Ahah, right… It actually doesn't add a panic, we just panic "outside" of the function instead of "inside" because it wouldn't make much sense to return a `Result` from `broadcast` as it is always the main function of its thread.

elegaanz (Migrated from github.com) reviewed 2018-12-27 00:23:18 +00:00

plume-common/src/activity_pub/request.rs

					
				@ -107,3 +107,3 @@

				pub fn signature<S: Signer>(signer: &S, headers: &HeaderMap) -> HeaderValue {

				pub fn signature<S: Signer>(signer: &S, headers: &HeaderMap) -> Result<HeaderValue, ()> {

				    let signed_string = headers

elegaanz (Migrated from github.com) commented

2018-12-27 00:23:18 +00:00

It says that it can either success with a HeaderValue, or fail with (), so we don't have much details about the error, we just know it failed, but it is probably enough to know that something failed in this function (or maybe not?)

It says that it can either success with a `HeaderValue`, or fail with `()`, so we don't have much details about the error, we just know it failed, but it is probably enough to know that something failed in this function (or maybe not?)

elegaanz (Migrated from github.com) reviewed 2018-12-27 00:24:10 +00:00

plume-models/src/blogs.rs

elegaanz (Migrated from github.com) commented

2018-12-27 00:24:10 +00:00

Yes, tests should panic every time something is wrong, so that they fail and that we now something is broken.

Yes, tests should panic every time something is wrong, so that they fail and that we now something is broken.

codecov[bot] commented

2018-12-27 12:10:07 +00:00

(Migrated from github.com)

Codecov Report

Merging #392 into master will increase coverage by 0.08%.
The diff coverage is 19.5%.

@@            Coverage Diff             @@
##           master     #392      +/-   ##
==========================================
+ Coverage   27.76%   27.85%   +0.08%     
==========================================
  Files          63       63              
  Lines        6302     7260     +958     
==========================================
+ Hits         1750     2022     +272     
- Misses       4552     5238     +686

# [Codecov](https://codecov.io/gh/Plume-org/Plume/pull/392?src=pr&el=h1) Report > Merging [#392](https://codecov.io/gh/Plume-org/Plume/pull/392?src=pr&el=desc) into [master](https://codecov.io/gh/Plume-org/Plume/commit/e2d5a5057c2009e25cbb0f5625de0d0ebe7875ca?src=pr&el=desc) will **increase** coverage by `0.08%`. > The diff coverage is `19.5%`. ```diff @@ Coverage Diff @@ ## master #392 +/- ## ========================================== + Coverage 27.76% 27.85% +0.08% ========================================== Files 63 63 Lines 6302 7260 +958 ========================================== + Hits 1750 2022 +272 - Misses 4552 5238 +686 ```

trinity-1686a reviewed 2018-12-28 16:42:39 +00:00

trinity-1686a left a comment

Owner

It seems good.
Some Result could/should be Result<()> instead.
The ? syntax is really helpful with error handling

It seems good. Some Result<T> could/should be Result<()> instead. The `?` syntax is really helpful with error handling

plume-models/src/blogs.rs

trinity-1686a commented

2018-12-28 15:58:56 +00:00

Owner

I could see a use for knowing how many posts were deleted, and at first at assumed it's what it was. But after re-reading it's telling how many blogs where deleted, so the Ok(_) will only be 1 any, am I right?

I could see a use for knowing how many posts were deleted, and at first at assumed it's what it was. But after re-reading it's telling how many blogs where deleted, so the Ok(_) will only be 1 any, am I right?

plume-models/src/instance.rs

trinity-1686a commented

2018-12-28 16:00:18 +00:00

Owner

If I'm not mistaken, the usize is going to be how many entries were affected, which is one?

If I'm not mistaken, the usize is going to be how many entries were affected, which is one?

plume-models/src/instance.rs

trinity-1686a commented

2018-12-28 16:00:35 +00:00

Owner

If I'm not mistaken, the usize is going to be how many entries were affected, which is one?

If I'm not mistaken, the usize is going to be how many entries were affected, which is one?

plume-models/src/posts.rs

trinity-1686a commented

2018-12-28 16:24:05 +00:00

Owner

I don't know if there are other places where unwrap_or_else(|_| ..) was replaced with unwrap_or(..), if so this comment also apply to them. I think it would be better to or_else(|_| ..)?, I think you already did it at other places

I don't know if there are other places where `unwrap_or_else(|_| ..)` was replaced with `unwrap_or(..)`, if so this comment also apply to them. I think it would be better to `or_else(|_| ..)?`, I think you already did it at other places

plume-models/src/tags.rs

trinity-1686a commented

2018-12-28 16:27:48 +00:00

Owner

Same about returning Result<()> because it will be 1

Same about returning Result<()> because it will be 1

plume-models/src/users.rs

trinity-1686a commented

2018-12-28 16:28:31 +00:00

Owner

same about Result<()>

same about `Result<()>`

trinity-1686a commented

2018-12-28 16:29:01 +00:00

Owner

Same about Result<()>

Same about `Result<()>`

trinity-1686a commented

2018-12-28 16:29:08 +00:00

Owner

Same about Result<()>

Same about `Result<()>`

src/main.rs

trinity-1686a commented

2018-12-28 16:35:26 +00:00

Owner

I should have made this message from the start. Maybe add something about making sure no other instance of plume is already running here?

I should have made this message from the start. Maybe add something about making sure no other instance of plume is already running here?

elegaanz (Migrated from github.com) reviewed 2018-12-28 17:31:56 +00:00

plume-models/src/blogs.rs

elegaanz (Migrated from github.com) commented

2018-12-28 17:31:56 +00:00

Yes, this result is not used anywhere, it just to have the right return type without having to .map(|_| ()), but maybe it's misleading?

Yes, this result is not used anywhere, it just to have the right return type without having to `.map(|_| ())`, but maybe it's misleading?

elegaanz (Migrated from github.com) reviewed 2018-12-28 17:32:51 +00:00

plume-models/src/instance.rs

elegaanz (Migrated from github.com) commented

2018-12-28 17:32:50 +00:00

Yes, but https://github.com/Plume-org/Plume/pull/392#discussion_r244369771

Yes, but https://github.com/Plume-org/Plume/pull/392#discussion_r244369771

trinity-1686a reviewed 2018-12-28 17:39:03 +00:00

plume-models/src/blogs.rs

trinity-1686a commented

2018-12-28 17:39:03 +00:00

Owner

I think it is, even more because we did not document any function (nor what they return)

I think it is, even more because we did not document any function (nor what they return)

elegaanz (Migrated from github.com) reviewed 2018-12-28 17:48:25 +00:00

plume-models/src/blogs.rs

elegaanz (Migrated from github.com) commented

2018-12-28 17:48:25 +00:00

Ok, I'll change it then. 👍

Ok, I'll change it then. :+1:

trinity-1686a approved these changes 2018-12-28 18:01:44 +00:00

trinity-1686a left a comment

Owner

👍

:+1:

Sign in to join this conversation.

No reviewers

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Plume/Plume#392

No description provided.