Hei. To perform some operation, I need to check if the parameter is null or not. So instead of using...

# arrow

[Satyam Agarwal]

Hei. To perform some operation, I need to check if the parameter is null or not. So instead of using Option I been doing IO.just(value).raiseIfNull { MyError }.
But I found that in some place i did IO { value }.raiseIfNull { MyError }. They both work. But I am wondering if IO { value } which is equal to IO.invoke { value } is costlier than IO.just(value). In my head it sound like yes, it should be costlier, because we know the value is pure so just should not do anything to validate that, and just is Pure(value) which is a data class that extends IO<A>().
So the question, is what I am thinking is true and using just and invoke interchangeably a bad idea ?

[stojan]

I guess using IO { pureValue } is not that bad

however using IO.just(println(Hello world)) is bad, because it not pure, will be immediately executed. IO {println("Hello world")} is pure, because it will be lazily executed, later.

just is the constructor for creating an IO from a pure value

[Satyam Agarwal]

okay. Thanks 🙂

[aballano]

RaiseError it’s indeed an IO state, but it’s fine calling it like that because is just gonna keep that Throwable until the IO is executed

[aballano]

the difference with just is that you could try to call a function with it and get an exception, which would crash your app, that’s why there’s a lazy version of it

[Satyam Agarwal]

right, thanks a lot 🙂

[stojan]

IO can succeed with a value or error with a Throwable. If you have a pure value, you already know if it's success or error hence two constructors.

If the value needs to be calculated lazily, then you do not know if it will succeed or error when executed, so one constructor for both success and failure in the lazy case is enough

[Satyam Agarwal]

I understand. Thanks a lot 🙂

[raulraja]

Also we will consider instantiating Throwables an effect

[raulraja]

because of the native call to fillInStackTrace which alters the performance of the program unless a user has manually overriden it in their custom exception.

[raulraja]

that means MonadThrow or any ApplicativeError parametric to Throwable are not correct because you would need MonadDefer and up. This can also help us solve many issues we have with Bracket

[raulraja]

I’m experimenting with a new encoding of types that allows for a BiFunctor type class hierarchy

[Satyam Agarwal]

Okay. I am kind of lost here, can you please dumb it down for me @raulraja?

I didn’t understand the part :

that means MonadThrow or any ApplicativeError parametric to Throwable are not correct because you would need MonadDefer and up. This can also help us solve many issues we have with Bracket

Also,
1. How can one opt in for not fillInStackTrace ? Because I get huge stack traces fro arrow when I log them, they are nice, but kibana doesn’t get happy.
2. What are the problems that arises with bracket because of this ?

[raulraja]

http://normanmaurer.me/blog/2013/11/09/The-hidden-performance-costs-of-instantiating-Throwables/

[raulraja]

You need to create your own exception types if you are using that to model and override fillInStackTrace to return your exception type

[raulraja]

But if you can avoid creating exceptions even better