@claudiameadows, yes I totally agree with you, if a value is undefined, we got both results an error is undefined and a value is undefined. But shouldn't we understand first was exception caught or not?
In the code:
const {caught, value} = try readFileSync('some file');
// wait a minute, what if there was read error
// that says we have no permission to read file
if (!value)
try writeFileSync('some file');
// we should definitely check was exception caught or not
// all our logic relies on this so the check will be one of
if (value instanceof Error)
throw value;
// or
if (caught)
throw value;
And again, value could be undefined, so we can't use instanceof, we should definitely check caught.
Undestand me right, I'like conception of Monad from Haskell, and the way Promises works, I just think that this implementation of Monad is not quite right, because the way how they works. If you talking about EatherMonad, it can be something like:
const eatherMonad = try readFileSync('hello');
eatherMonad(okFn, failFn);
// or
eahterMonad
.then(fn)
.catch(fn);
But we already have promises for this purpose: to have ability not use if statement. But current try implementations doesn't provide a way to avoid if, so I don't think that this can be compared to Monad.