I am so proud to announce the 1.0.0 release of cardano-wallet. A fully object oriented JavaScript Library built on top of the Cardano SDK.

It has been a while since my last blog post here. I have been working on a new project for a blockchain company IOHK. My team has been working on the project to broader the customer targets by allowing the development of 3rd party software to work on many different platforms.

ShareSafe is available and ready to use. It allows users to leverage Publicly Verifiable Secret Sharing (PVSS).

Being a haskell library provider means you have a contract toward your user: you provide them with a minimum degree of confidence your code work.

This is quite important. And thankfully Haskell maintainers are quite good with that. The language provides the abstraction to avoid the common mistakes; the semantic is checked at compile time. But what about the implementation itself? Or the properties? Is it correct? Is your functor actually a functor? Will it behave like everyone is expecting? Is your JSON parser parsing the data as expected?

I came across a problem that needed to use Haskell's Type Literals.

Haskell's Type Literals enable a new world of possibility in APIs and help solve day to day developer issues.

In a previous post I demonstrated how handy error handling in Haskell and in Rust is.

It is possible to do the same in C++.

Too often I come along the problem of error handling in C++. Some believe we must use exceptions, others prefer the old C style error code.

I believe both are good options and have valid concerns about the other. I believe we should do both.

I have been a C++ developer for a little while, I have seen different methods to provide meaningful API:

• the C-like: using error code and returning output in the parameter;
• the exception-like: using exceptions.

The difficulties are to:

• guarantee that the error handling is documented;
• ensure it does not change (requires a lot of regression tests);
• keep undefined behaviours as "exceptional".

That's it: exceptions are for exceptional situations. And again, it is not easy to provide up to date documentation of the kind of exceptions your function may throw.

So, let's try something else. Let's see what other languages have done to try to solve the issue of non self documented APIs.