DEV Community

loading...
Cover image for Developer eXperience: error messages

Developer eXperience: error messages

#dx
stereobooster
Hello, I'm a full stack web developer. Follow me on Twitter!
Originally published at stereobooster.com Updated on ・3 min read

Let's talk about error messages and warnings in developer tools, like compilers, linters type checkers etc.

Clear error messages

I guess the trend of clear error messages is started by Elm. At least I haven't seen that clear messages before. After Elm trend was picked up by JS, ReasonML, Ocaml, Rust etc.

Clear error messages make the learning curve much easier, especially if there is a very strict type system, basically, type checker turns into an interactive tutorial.

If error messages are unclear, you need to search the error on the internet. You will be lucky if there is a page which explains what the issues, for example import/first. But there can be a long discussion in the GitHub and you need to scan all comments to find an answer, for example Warning: Critical dependencies. It would save a lot of time if the error message would clearly explain how to fix the it, without the need to search for it, without the need to switch context.

I wonder why it hasn't happened before. I guess because it is an additional task, you need to write additional code to make error messages clear. See, for example, Constructing human-grade parsers.

Noise in the logs

For better DX, it is required to limit the output of warnings, debug messages, because if there will be a lot of repetitive or unrelated information programmer will develop blindness for the messages. I saw a couple times where developers struggle to solve the issue even that error message clearly explained what to do - they simply didn't read it, because they get used to noise in logs. For example:

FAILED: src/ListItem.mlast
reason-react-hacker-news/node_modules/bs-platform/lib/bsc.exe -pp "reason-react-hacker-news/node_modules/bs-platform/lib/refmt.exe --print binary" -ppx 'reason-react-hacker-news/node_modules/bs-platform/lib/reactjs_jsx_ppx_2.exe'   -w -30-40+6+7+27+32..39+44+45+101 -nostdlib -I 'reason-react-hacker-news/node_modules/bs-platform/lib/ocaml' -bs-no-version-header -bs-super-errors -no-alias-deps -color always -c -o src/ListItem.mlast -bs-syntax-only -bs-binary-ast -impl reason-react-hacker-news/src/ListItem.re
File "reason-react-hacker-news/src/ListItem.re", line 30, characters 24-25:
Error: 3355: <UNKNOWN SYNTAX ERROR>

  We've found a bug for you!
  reason-react-hacker-news/src/ListItem.re

  There's been an error running Reason's refmt parser on a file.
  This was the command:

  reason-react-hacker-news/node_modules/bs-platform/lib/refmt.exe --print binary 'reason-react-hacker-news/src/ListItem.re' > /var/folders/sd/gvj7n1494zj86l861747vbd00000gn/T/ocamlppc688eb

  Please file an issue on github.com/facebook/reason. Thanks!

ninja: error: rebuilding 'build.ninja': subcommand failed

And the important part is:

File "reason-react-hacker-news/src/ListItem.re", line 30, characters 24-25:
Error: 3355: <UNKNOWN SYNTAX ERROR>

Everything else will not help to fix the error.

Photo by Matthew Brodeur on Unsplash

Discussion (1)

Collapse
codevault profile image
Sergiu Mureşan • Edited

I can safely attest the fact that log message blindness is a thing. A couple weeks ago I had some dependency issues in .NET and couldn't figure out any solution after trying for a couple hours until... you guessed it... I looked at the log:

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3247: 
Found conflicts between different versions of the same dependent assembly. 
In Visual Studio, double-click this warning (or select it and press Enter) to fix the conflicts; 
otherwise, add the following binding redirects to the "runtime" 
node in the application configuration file: 


<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly><assemblyIdentity name="Newtonsoft.Json" culture="neutral"
 publicKeyToken="30ad4fe6b2a6aeed" /><bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0" /></dependentAssembly></assemblyBinding>

Right there, the problem AND the solution. I was face-palming so hard after I saw that. Sadly, both our build log and our front-end console log is flooded with useless information, part our fault, part Visual Studio's.

The main takeaway from this... read the build log if you have build errors.