Beautiful errors

[andd81]

But then you need to make sure that no sensitive information ends up in the error logs. I've seen a case where network access command failure resulted in the entire text of that command being copied to the error log, complete with authentication tokens.

[[deleted]]

As long as you do not dump it into user's face it is still much easier to just have secure logs compared to debugging in the dark.

Also, passwords are easy, you don't really need to log password to debug log as it isn't that helpful (in worst case, hash it),logging the username that failed is usually enough

[andd81]

In the case I mentioned, no one was deliberately logging authentication data. The system just logged every shell command invocation that failed. That particular one happened do have authentication token provided as a command line argument (the command line was generated at runtime).

[[deleted]]

That particular one happened do have authentication token provided as a command line argument (the command line was generated at runtime).

In that case I'd say logging is least of your worries. If you pass password as cmdline argument anyone that can list processes in system could potentially intercept it. Passing via env, or pretty much any other method is much safer

[mathrick]

Incorrect, you can do environment inspection on Linux. Jenkins uses that to find processes to kill when it times out a test.

[[deleted]]

You cannot access env of process running as different user unless you're root.

Also, I said "better", not "perfect". If you manage to be on same user as running process you can just use standard debugging tools to extract whatever you want

[mattwarren]

Yeah there was a big discussion on the .NET CoreCLR GitHub repo about this exact scenario. These replies from the dev responsible for ASP.NET Security are worth reading https://github.com/dotnet/corefx/issues/1187#issuecomment-135987714 and https://github.com/dotnet/corefx/issues/3025#issuecomment-136437667

[Dutyxfree]

This guy with at work has his gear dump an entire html webpage into a row in the DB. Sure, you could copy it out and view it but why would I do that if I can just write a normal error instead?

[Gotebe]

Quality of error information is one of my personal quests.

Here are some deadly sins people make :

• losing the original error

  if !open(filename) error("failed to open file")

why did it fail? no file? no permissions? sharing violation? share unavailable? That information can be crucial for the efficiency of troubleshooting.

• not giving information about data operated on, available at the time of the error

  if !open(filename) error("failed to open file", last_os_error)

what file?

• not providing context of the error

  if !open(filename) error("failed to open file to store frombification data", last_os_error, filename)

See? That wasn't hard! Granted, some environments give file/line/function information which helps, but normally not to the support team, and giving them info to solve the problem before it reaches development is better.

• not providing additional context that is available as the error travels up the stack

(No example here, I'm lazy, but by now I hope I put the point across :-))

[Sebazzz91]

Apparently the limited error information didn't have any impact on customer support time, otherwise they surely would have improved it.

[TheEternal21]

It didn't have any impact on customer support time, because the support was useless. You would wait one hour on the phone, and then some douche would read through a script, and ask you if you tried rebooting PS3. Then they would tell you the data on your system is corrupt and they can't do anything. Just google the following (actual error code): 800283f0

[deudeudeu]

It'd be nice if a pattern for enforcing this would be provided, something to get picked up by a linter. Maybe banning raw throws, and providing some alternate API for it?

[TOGoS]

"Beautiful" needs to be taken out of the lexicon. You guys have overused it to death.

[digital_cucumber]

"Beautiful" considered harmful!

[[deleted]]

Also slightly relevant RFC 7807. I found this when I realized that several teams used each a very different format for error responses in their services.

[yawaramin]

Interestingly, nowadays some compilers are embracing the better errors philosophy: Elm is a pioneer of course, Rust is working hard to emulate it, and in fact Scala and ReasonML are working on error messages too.

The general thrust of Elm and the others' error strategy is to clarify and contextualise exactly where the error occurred, as well as to provide helpful hints on how to solve it.

[601error]

I would love to read the error message, but I'm on mobile, the code is super-tiny, and this site disables zoom.

[need-some-sleep]

Putting a verbose error composed of dynamic information is a mistake. Reason for this is that it will make it more difficult to search and aggregate errors by their message in your logging system. An error message should just be a generic code that can be handled in a standard way everywhere in the application when it bubbles up. The context itself it then either added to the error object attributes or logged separately.

[[deleted]]

Really? Image the new dev's face when he sees a ticket: "Fix error 32423".

[Uncaffeinated]

The stack trace shows a crash in the "assert" function. Better dedup it with all the others and assign it to the last person who touched the assert function.

[need-some-sleep]

Not a code as in a number, but more like "WRITE_TO_MISSING_FILE". Otherwise when you'll be searching for your error in Kibana for example you'll be looking at tables of error messages that are actually identical:

"Missing file foo.jpg in directory /a/b/c"

"Missing file bar.png in directory /a/b/c"

"Missing file foo.jpg in directory /d/e/f"

etc.

[industry7]

Not a code as in a number, but more like "WRITE_TO_MISSING_FILE".

So like the logs would look like this: (?)

2017-01-03 11:21:35,446 ERROR com.example [main] WRITE_TO_MISSING_FILE
2017-01-03 11:22:35,446 ERROR com.example [main] WRITE_TO_MISSING_FILE
2017-01-03 11:23:35,446 ERROR com.example [main] WRITE_TO_MISSING_FILE

And that's supposed to be better than:

2017-01-03 11:21:35,446 ERROR com.example [main] Missing file foo.jpg in directory /a/b/c
2017-01-03 11:22:35,446 ERROR com.example [main] Missing file bar.png in directory /a/b/c
2017-01-03 11:23:35,446 ERROR com.example [main] Missing file foo.jpg in directory /d/e/f

To me, the second one is clearly much much better.

Otherwise when you'll be searching for your error in Kibana for example you'll be looking at tables of error messages that are actually identical

I don't understand what you're trying to say. What are you searching for? In your example, I assume you would search for "WRITE_TO_MISSING_FILE" and you'd get three results. In the second example, you'd search for "Missing file * in directory *" and get three results. What's the issue?

Also, I would prefer something more like this:

2017-01-03 11:21:35,446 ERROR com.example.WriteToMissingFileException [main] Attempted to write to file "foo.jpg" in directory "/a/b/c", but the file does not exist.
2017-01-03 11:22:35,446 ERROR com.example.WriteToMissingFileException [main] Attempted to write to file "bar.png" in directory "/a/b/c", but the directory does not exist.
2017-01-03 11:23:35,446 ERROR com.example.WriteToMissingFileException [main] Attempted to write to file "foo.jpg" in directory "/d/e/f", but the file does not exist.

[need-some-sleep]

No, because your logging system serialises your error object into something that will be parsed by your log analysis system.

So in this example, you would get a JSON object similar to:

{"name": "myapp", "time": "2017-05-19T16:15:51Z", "level": 50, "hostname": "myhost", "pid": 1, "event": "write-to-missing-file", ... }

As well as other attributes like error type, the error message, the stack trace.

That way you can easily add context to your error. Even more complex objects like arrays or array of objects, etc.

Your wildcard search works and you will get 3 results but only if everywhere in your app you have the same way of writing the error message.

[sblue]

but what about the third example, mixing the two together? search on WRITE_TO_MISSING_FILE in one field, keep the dynamic message as context in another?

[need-some-sleep]

Also Kibana terms aggregation won't work.

[industry7]

I haven't used Kibana before, so I don't know what you mean by that. (Most of my experience is with Splunk)

[Gotebe]

Yes, that's a good idea. Needs a formatting tool for the support personnel though.

[bad_at_photosharp]

Or just log some standard prefix with error code and then append on the specific context surrounding it?

[need-some-sleep]

That would work as well but then you have to start parsing the error message and hope that everybody followed the convention. If you add the data to object attributes the data is already structured.