Oliver

Oliver

Currently I have in my project two ways to make a stack trace:

One function to be used in try-blocks piping __STACKTRACE__ into Exception.format_stacktrace/1 and then into the Logger.

And one that calls uses Process.info/2 and then formats that with Exception.format_stacktrace_entry/1 similar to Exception.format_stacktrace/1 without arguments.

The reasoning is this: The implementation of Exception.format_stacktrace/1 is like this:

      if trace do
        trace
      else
        case Process.info(self(), :current_stacktrace) do
          {:current_stacktrace, t} -> Enum.drop(t, 3)
        end
      end

In all cases where I tried to use it, it shaved off the immediate caller (like the module used for callbacks in a GenServer) and left me with “the uninteresting part” (the stack trace elements pertaining to :gen_server, for example). Might it not be better to do a tl(t) here? (Then it just removes the entry for Process.info/2.)

The other thing is about the __STACKTRACE__ special form. It is not usable outside catch/rescue. But wouldn’t it be handier if it just returned nil in all other contexts?

Then you could always pipe it into Exception.format_stacktrace/1 and reuse the same code everywhere.

I admit in my case it would be a minor improvement, but currently the user has to always decide which of my two stack trace functions to call.

Showing Posts 1 to 1

Oliver

Oliver OP

Ah, sorry, I just redid my code and realized that one of these two was my bad:

I called Exception.format_stacktrace/1 from inside a macro’s quote block which changes the stacktrace. Now that I converted my code into a function I see why the first three entries were removed.

— All posts loaded —

Where Next? Top

Trending in Discussions Top

cblavier
Hey there, It’s been more than a year since we started using LiveView as our main UI library and building a whole library of UI componen...
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
mhanberg
Hi everyone! The first release candidate for the Expert language server project is now available! We’ve published a press release detai...
New
budgie
A little off-topic, but I feel like people here have a good head on their shoulders. I used to be quite good at making software. Was luc...
New
axelson
Hi there! :wave: @frigidcode and I (but mostly him) have been running an Elixir Book club, we’re almost done with Designing Elixir Syste...
New
achempion
I’ve been using Emacs as my main code editor for more than a two years. It’s a custom build version although I’ve tried doom emacs and sp...
New
budgie
I love Elixir. It’s one of 2 programming languages I’ve ever fallen in love with. But I don’t use it anymore. Serverless was the promis...
New

Other Trending Topics Top

GenericJam
Edit: 2026 May 15 - This post is archived. Mob is alive!! Main docs: mob v0.7.11 — Documentation A bit of explanation for the slightly c...
New
JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
KristerV
Hey. Is there anyone here who creates agents in their apps? Not talking about using agents, but creating them. I’m finding it pretty diff...
New
mcass19
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
georgeguimaraes
Just published claude-code-elixir, a plugin marketplace for Claude Code with Elixir support. These are the plugins I’ve been using for my...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews