How to discover which error needs to be handled

[gentle adder]

Hi ! I was trying to test a basic irc client with this part of code:

    for {
        msg, err := tp.ReadLine()
        if err != nil {
            if errors.Is(err, net.ErrClosed) {
                break
            }    
            slog.Error("Readline()", "error", err)
        }

        fmt.Println(msg)

        if strings.HasPrefix(msg, "PING") {
            bot.pong(msg)
        }
    }

but I was wondering how am I supposed to know that the error I can get is net.ErrClosed ?
when I tried to print it using %#v it showed 2026/02/24 12:59:49 &net.OpError{Op:"read", Net:"tcp", Source:(*net.TCPAddr)(0xc00009a960), Addr:(*net.TCPAddr)(0xc00009a990), Err:poll.errNetClosing{}} which doesnt show that specific error name, and poll is an internal package.
and the string representation tells the error but not the name itself.
is there a common/practical/simple way to know what error a function can return ?

[honest yacht]

all errors need to be handled and rarely is an error not an issue (io.EOF being one of the rare exceptions)

maybe half close on a socket being similar

[gentle adder]

I meant, how do I know precisely which error it is, here for example net.ErrClosed, there isnt a list of error the function returns

[honest yacht]

what’s the type of that ReadLine ?

(tp’s)

and no there isn’t a list outside of documentation because again in most cases errors are just bad and the details of how just for logging (unless documented/ there are package errors)

[gentle adder]

tp is tp := textproto.NewReader(bufio.NewReader(bot.conn))

and no there isn’t a list outside of documentation because again in most cases errors are just bad and the details of how just for logging (unless documented/ there are package errors)
I am not sure to understand what you mean

[honest yacht]

I don’t know that package but net.ErrClosed is documented. and I was trying to say that maybe it should be logged like any error and all errors should do “break” out of the loop

[gentle adder]

I understand what you mean about breaking the loop and that net.ErrClosed has documentation, but I am asking if there is a way to know what error is there to handle, for example if I wanna do a switch case on the err and do something specific depending on the returned error, how can I know what error name I should use ?
that part is not documented, and if the only way to know is to read the source code of textproto.ReadLine then textproto.readLineSlice etc. until I finally can see the returned error, thats terrible, so there must be another way ?

[faint acorn]

there is no other way

the type system allows any type implementing an interface to serve as a value of that interface, so documentation is the only way to communicate it, and without that it’s down to reading the code

[honest yacht]

and to beat a dead horse, if you would need to know more than 1 or 2 specific error type it would be a poorly designed (and documented) api

[gentle adder]

Well I’m not designing an API but just a simple cli program
And all I needed to know is to not error when that specific case arise and like @faint acorn said, it’s just not possible to know in an easy way since the documentation of textproto doesn’t specify the errors it can return

[honest yacht]

what I have said a few times already is that all the errors from that package are basically to be treated… as errors

[gentle adder]

is it hard to understand that I simply wanna switch case those error and do specific things depending on the one I got ?

errors are made to be handled, different kind of error are made to be handled differently

[honest yacht]

go doesn’t have checked exceptions, errors when they need to be treated specifically are documented, or discovered after 10s of testing

and to repeat one last time you’re treating closed wrong

[gentle adder]

not only this is irrelevant, but it's also wrong for what I am doing

If "10s of testing" is the only way to find out which error a library returns, that confirms my point that the documentation is lacking.

As for "treating closed wrong" what is the "right" way to distinguish a deliberate connection close from a read timeout/packet loss without checking the error type ?
I want my cli to exit cleanly on close, not panic or print a stack trace

[faint acorn]

when you’re providing a value which could return an error (on two levels here, with the net.Conn and bufio.Reader), it’s somewhat implicit that errors returned by that value could bubble up

textproto has no idea what errors could be returned because you’re the one providing the reader, and it’s taken as obvious enough that it’s not worth saying “errors returned by arguments to the function may be returned” for every single function that takes in an error-producing parameter

a package often will document its errors if it believes there’s a decent chance that the caller may want to handle some situation specially

(which is why net does document and explain net.ErrClosed)