Print methods of the Console effect should not depend on Abort[IOException]

[rcardin]

The Scala Console.println doesn't throw an IOException. The method uses the Java PrintStream type, which fails silently in case of errors. So, the kyo.Console effect should not depend upon an Abort[IOException] for printing text on the console.

We should rewrite the code such that the examples in the documentation will change accordingly:

val b: Unit < IO = Console.print("ok")

// Print to stdout with a new line
val c: Unit < IO = Console.printLine("ok")

// Print to stderr
val d: Unit < IO = Console.printErr("fail")

// Print to stderr with a new line
val e: Unit < IO = Console.printLineErr("fail")

// Explicitly specifying the 'Console' implementation
val f: Unit < IO = Console.let(Console.live)(e)

See PrintWriter and PrintStream never throw IOExceptions for further details.

[sideeffffect]

Or rather, in the relevant Console operations, run the PrintWriter#checkError /PrintStream#checkError method and raise a Kyo error if needed.

[rcardin]

I think here we need a decision by @fwbrasil ☺️.

By the way, since the exception suppression was intentional, I would give hope to Java designers. Do you want your whole application to stop working because you can't write logs? There are cases when I would say yes and cases when I would say no 🤷‍♂️.

[rcardin]

The problem is that we've not thrown IOException. For example, it follows the code inside the PrintStream:

public void write(int b) {
    try {
        if (lock != null) {
            lock.lock();
            try {
                implWrite(b);
            } finally {
                lock.unlock();
            }
        } else {
            synchronized (this) {
                implWrite(b);
            }
        }
    }
    catch (InterruptedIOException x) {
        Thread.currentThread().interrupt();
    }
    catch (IOException x) {
        trouble = true;
    }
}

We would need a dedicated domain error.

[sideeffffect]

Do you want your whole application to stop working because you can't write logs?

That should be up to the application developer. I believe it's trivial to suppress/ignore errors in Kyo. But for that to happen, the errors must not be hidden from the application developer in the first place.

[rcardin]

You're right. The only concern is that we cannot access the original IOException.

[johnhungerford]

This is interesting. Looks like ZIO makes the same mistake. I'm kind of inclined to drop the IOException rather than make some effort to uncover the failure because whether or not people are aware of it, this is the behavior they are used to and will be expecting.

[fwbrasil]

I agree with dropping the pending Abort[IOException] since it matches the behavior of the underlying implementation and simplifies effect tracking. It'd be nice to also expose a method to check for errors, though

[rcardin]

I can work on this 😄

[sideeffffect]

this is the behavior they are used to and will be expecting

That may be true. But that doesn't change the fact that errors may happen. And if the Kyo signature doesn't reflect this, then it's lying to its users.

matches the behavior of the underlying implementation

True, but the underlying implementation itself is designed in a ways which is misleading to its users.

simplifies effect tracking

All the work to build this sophisticated effect tracking system, only to not use it when needed? :)

It'd be nice to also expose a method to check for errors

Isn't Abort[...] precisely such Kyo-idiomatic way to check for these errors?

[johnhungerford]

I think @fwbrasil was suggesting that we have a set of Console methods that work like the standard Java methods (i.e., they swallow errors) and a second set of methods that expose errors using `Abort[IOException]`.

…

On Thu, Jan 23, 2025 at 6:13 AM Ondra Pelech ***@***.***> wrote: this is the behavior they are used to and will be expecting That may be true. But that doesn't change the fact that errors may happen. And if the Kyo signature doesn't reflect this, then it's lying to its users. matches the behavior of the underlying implementation True, but the underlying implementation itself is designed in a ways which is misleading to its users. simplifies effect tracking All the work to build this sophisticated effect tracking system, only to not use it when needed? :) It'd be nice to also expose a method to check for errors Isn't Abort[...] precisely such Kyo-idiomatic way to check for these errors? — Reply to this email directly, view it on GitHub <#1037 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGEA2MK7BOSUXMY4CY3HQWL2MDFGZAVCNFSM6AAAAABVRDHXF2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBZGUZTGOBSHE> . You are receiving this because you commented.Message ID: ***@***.***>

[rcardin]

Despite the final solution, we need to fix the current implementation since it's saying it can fail with an IOException, but it can't 🤷‍♂️

[fwbrasil]

I had in mind exposing a single method like Console.checkErrors: Unit < (IO & Abort[IOException]).

All the work to build this sophisticated effect tracking system, only to not use it when needed? :)

To be frank, for some time I wasn't even convinced that tracking failures in Kyo's APIs made sense. This is a good example since people have been using these Java APIs for many years. I imagine the vast majority don't know of this quirk and it didn't even matter. I can see more value in tracking failures now, especially given Kyo's more flexible support allowing proper handling of specific failures, but I don't see it as a all-or-nothing decision.

In the case of Console, it's a common API for newcomers to use so reducing the effect tracking overhead can easily outweigh the benefits of exposing Abort[IOException]. Also, people might use it for debugging and the introduced pending effect can require additional changes. I believe a checkErrors method and documentation of the behavior via scaladocs is enough to provide a good user experience in general.

[fwbrasil]

@hearnadam could you share your thoughts on this?

[hearnadam]

Given the precedence of Java doing the 'wrong' thing, we probably should too. Yes, it would be 'optimal' in some senses to do the right thing (validating the program works as expected/ensuring output), however I think the usability concern of debugging/newcomers is reasonable. I wouldn't expect production projects to use Console, though I could be wrong.

[rcardin]

Thanks to everybody for sharing his point of view, so, summing up:

1. We'll remove the Abort[IOException] effect from the kyo.Console.print family of methods
2. We'll add a Console.checkErrors: Unit < (IO & Abort[IOException]) to check if there was an error.

Is it correct?

[fwbrasil]

Yes, I think that's it. About checkErrors, in case we don't have access to the underlying exception, we could return a Boolean < IO.

[rcardin]

Ok, let's do it!

[hearnadam]

@rcardin are you still interested in PR'ing this?

[rcardin]

Yep, sorry, I’m having a busy week. Do we have a deadline?

[hearnadam]

No, take your time!

[rcardin]

I will try to open the PR at the latest by this Friday