Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ref/haskell: refactor error handling for bech32Decode #41

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

manifoldhiker
Copy link

The main reason to refactor was the Maybe in a signature. It is not clear why the given bech32 string is invalid.

@manifoldhiker manifoldhiker reopened this Mar 15, 2018
@manifoldhiker manifoldhiker reopened this Mar 15, 2018
@manifoldhiker manifoldhiker changed the title [LTB-7] Refactor error handling ref/haskell: refactor error handling for bech32Decode Mar 15, 2018
maybeToRight :: l -> Maybe r -> Either l r
maybeToRight l = maybe (Left l) Right

verify :: Bool -> a -> Either a ()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel that this would work better with the argument order reversed. Then it would be similar to maybeToRight.

@@ -75,19 +77,19 @@ tests :: TestTree
tests = testGroup "Tests"
[ testCase "Checksums" $ forM_ validChecksums $ \checksum -> do
case bech32Decode checksum of
Nothing -> assertFailure (show checksum)
Just (resultHRP, resultData) -> do
Left err -> assertFailure (show checksum ++ show err)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

something like intercalate ", " [show checksum, show err] would stop the assert failure message from being smooshed together.

@@ -156,4 +177,14 @@ segwitDecode hrp addr = do
segwitEncode :: HRP -> Word8 -> Data -> Maybe BS.ByteString
segwitEncode hrp witver witprog = do
guard $ segwitCheck witver witprog
bech32Encode hrp $ UnsafeWord5 witver : toBase32 witprog
rightToMaybe $ bech32Encode hrp $ UnsafeWord5 witver : toBase32 witprog
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think foo . bar $ x is preferred to foo $ bar $ x generally speaking. But this isn't show-stopping.

-- test that a corrupted checksum fails decoding.
let (hrp, rest) = BSC.breakEnd (== '1') checksum
Just (first, rest') = BS.uncons rest
checksumCorrupted = (hrp `BS.snoc` (first `xor` 1)) `BS.append` rest'
assertBool (show checksum ++ " corrupted") $ isNothing (bech32Decode checksumCorrupted)
assertBool (show checksum ++ " corrupted") $ isLeft (bech32Decode checksumCorrupted)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be isError ChecksumVerificationFail instead of isLeft?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, the choice of corruption sometimes produces invalid characters.

assertEqual (show checksum ++ " re-encode") expectedChecksum checksumEncoded
, testCase "Invalid checksums" $ forM_ invalidChecksums $
\checksum -> assertBool (show checksum) (isNothing $ bech32Decode checksum)
\checksum -> assertBool (show checksum) (isLeft $ bech32Decode checksum)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here: Shouldn't this be isError ChecksumVerificationFail instead of isLeft?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay I see these fail for various different reasons.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants