4 ms·
> It may not have the information on the filename or the line of code like the ordinary stack traces, but these are useless information anyway. That is the wei
by boxed 2y ago
> It may not have the information on the filename or the line of code like the ordinary stack traces, but these are useless information anyway.
That is the weirdest and most crazy thing I've read in years.
- cies 2y agoYeah, that's also my main problem with the article. Otherwise great to prmote TSTs. I think the TSTs should also contain the stacktrace. Not or X or Y, but both X and Y.
- arwhatever 2y agoNo doubt it’s harder to write structured code and assertions against a string stacktrace, but as a human reading it, the information is immensely valuable.
- twic 2y agoThe whole post feels like it came from a parallel universe. People adopted microservices because stack traces are too long! Exposing the implementation details of a function in its type signature is good! The most meaningful way to specify a function is by how it can fail (this one is fun, though)!
- antigeox 2y agoIn soviet F# the monads... uh....
- johnnyjeans 2y agothe endofunctors operate on the category of you!
- moi2388 2y agoI’ve been told by HR I’m not allowed to show people my endofunctor anymore..
- stonemetal12 2y agoDepends on how your app is structured, but it very well can be. badvalue = dobadthing(); dostuffwith(badvalue); Depending on the indirection between dobadthing() and the place that chokes on badvalue the stack trace can be completely worthless. It is one of the reasons people hated the original Spring. Claimed it decoupled stuff but all it really did was obfuscate. I have seen similar claims made about Clojure. Bad data coming from somewhere, but no way to trace it through the system. Sure you can filter bad data in to the garbage can, but that just masks the issue not fix it.