tfwright

tfwright

Posting this in discussions because it’s more of an open question about API design/conventions, but while looking through the documentation around streams, I found myself wondering why File includes a stream! function whereas IO has stream. According to specs, both functions appear to work similarly, returning an Enumerable directly (not wrapped in a tuple), and neither mentions any error cases I noticed, so why the different name?

My impression was that there is a pretty strong convention that a ! suffix in a function should always indicate that an error could be expected in certain conditions, whereas a function without ! should never be expected to return an error, but could return either a “status tuple” (actually not sure if there’s a more technical term for {:ok, res}/{:error, res} return values) or a result more directly, which I guess would mean that IO.stream is more “correct,” since, unlike File.read!, File.stream! will not error even when the path is invalid, etc?

Mostly just curious because I am designing a stream API for one of my own modules where most of the functions return status couples, but I don’t foresee any error cases for the streaming API. Appreciate any input!

Showing Posts 1 to 2

al2o3cr

al2o3cr

File.stream! has a line that’s easy to miss in the docs:

Operating the stream can fail on open for the same reasons as File.open!/2

“Operating” is the key part - you can File.stream! things that don’t exist, and you won’t get the exception until something forces the stream.

For instance:

iex(1)> File.stream!("nosuchfile.txt")

%File.Stream{
  line_or_bytes: :line,
  modes: [:raw, :read_ahead, :binary],
  path: "nosuchfile.txt",
  raw: true
}

iex(2)> File.stream!("nosuchfile.txt") |> Enum.to_list()

** (File.Error) could not stream "nosuchfile.txt": no such file or directory
    (elixir 1.13.0) lib/file/stream.ex:83: anonymous fn/3 in Enumerable.File.Stream.reduce/3
    (elixir 1.13.0) lib/stream.ex:1517: anonymous fn/5 in Stream.resource/3
    (elixir 1.13.0) lib/enum.ex:4143: Enum.reverse/1
    (elixir 1.13.0) lib/enum.ex:3488: Enum.to_list/1

IO.stream can’t fail in any of these ways since it takes either a PID (that you’d get from calling File.open! and possibly getting an exception) or an atom (to refer to stdio), so it doesn’t get a !.

tfwright

tfwright OP

So I didn’t notice that actual line but I’m certainly familiar with the behavior that a File stream will fail when you try to iterate on it. I am less familiar with working with IO streams though so that was probably a bad assumption of mine that there were some cases that might cause an error at that point. I guess it’s just that lazy evaluation is an interesting edge case for this convention. My first reaction is that even if using the stream might create an error at a certain point, the function name should only express the possible return values, but it’s clear why that would be difficult to adhere to in this case.

Interestingly, my case involves different stream sources so it complicates even further. if a stream API might return an IO stream or a File stream, how should it be named? stream! because in certain conditions an error might be raised on iteration? :thinking:

— All posts loaded —

Where Next? Top

Trending in Discussions Top

AstonJ
As the title says, please share what you’ve been up to with Elixir. Whether that’s been learning it, looking into it, making stuff with i...
2977 92995 915
New
caslu
I want to open this thread for you all to discuss and help those who really like Ash but are still hesitant to use it in a real project. ...
New
mudasobwa
I am happy to introduce the very α version of the new programming language compiled to BEAM. Welcome Cure. It has literally three kille...
New
GES233
I’m posting this in response to Jose’s recent tweet (Cr. link) : People are sleeping on Elixir for a coding harness: Hot-code swappi...
New
marciol
It would be helpful to have a list of companies worldwide that hire engineers without prior experience in Elixir. Often, it can be quite ...
New
durvia
Anyone running long-lived stateful processes on BEAM? We’re building an AI agent runtime and would love to compare notes. We’re a small ...
New
nseaSeb
I’ve just put together a small POC exploring PDF inspection from Elixir/Phoenix: The idea is pretty simple: drag & drop a PDF in a...
New

Other Trending Topics Top

garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
marciok
Hi there! We created Gust: A task orchestrator inspired by Airflow. For those who have never heard about Aiflow, it’s a Python-based wor...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
Dmk
Xamal is a deployment tool for Elixir apps that deploys native releases to bare metal servers over SSH. It’s a port of GitHub - basecamp/...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve. They are GUI (Emerge) and State management (S...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews