From: "mame (Yusuke Endoh)" Date: 2021-09-27T08:02:46+00:00 Subject: [ruby-core:105442] [Ruby master Bug#18194] No easy way to format exception messages per thread/fiber scheduler context. Issue #18194 has been updated by mame (Yusuke Endoh). I think that we need to clarify the issue first. > an error message might be formatted for both the terminal and a log file, which have different formatting requirements. I completely agree with this. For the terminal, we may want to see colors by escape sequences, and detailed explanation like did_you_mean and error_highlight. For a log file, a simple one-line message is often enough. This issue is also pointed by @byroot in https://github.com/ruby/error_highlight/pull/10 . The subject of this ticket proposes to make the configuration per-thread, but I don't think that it is a good solution against the issue. I think we want to use the different formats even in a simple thread application. How about focusing on only this issue of tty and a log file? Mixing other ideas like "per-thread" and "metadata" would complicate things. My naive idea is to add to the interpreter a new method `Exception#detailed_information` that returns an additional text to help users understand the error, to let did_you_mean and error_highlight define `Exception#detailed_information` instead of overriding `Exception#message`, and to let the interpreter show `Exception#message` and `Exception#detailed_information` in turn when an uncaught exception occurs. For a log file, using only `Exception#message` would be enough. ---------------------------------------- Bug #18194: No easy way to format exception messages per thread/fiber scheduler context. https://bugs.ruby-lang.org/issues/18194#change-93889 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: mame (Yusuke Endoh) * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- In the new error highlighting gem, formatting exception messages appears to be per-process which is insufficiently nuanced for existing use cases. As in: ```ruby class TerminalColorFormatter def message_for(spot) # How do we know the output format here? Maybe it's being written to a log file? "..." end end ErrorHighlight.formatter = TerminalColorFormatter.new ``` But we won't know until the time we actually write the error message whether terminal codes are suitable or available. Or an error message might be formatted for both the terminal and a log file, which have different formatting requirements. There are many consumers of error messages an some of them produce text, or HTML, or JSON, etc. Because of this design we are effectively forcing everyone to parse the default text output if they want to do any kind of formatting, which will ossify the format and make it impossible in practice for anyone to use anything but the default `ErrorHighlight.format`. For what is otherwise a really fantastic idea, this implementation concerns me greatly. I would like us to consider introducing sufficient metadata on the exception object so that complete formatting can be implemented by an output layer (e.g. logger, terminal wrapper, etc). This allows the output layer to intelligently format the output in a suitable way, or capture the metadata to allow for processing elsewhere. In addition, to simplify this general usage, we might like to introduce `Exception#formatted_message`. In order to handle default formatting requirements, we need to provide a hook for formatting uncaught exceptions. This would be excellent for many different use cases (e.g. HoneyBadger type systems), and I suggest we think about the best interface. Probably a thread-local with some default global implementation makes sense... maybe even something similar to `at_exit { ... $! ... }`. -- https://bugs.ruby-lang.org/ Unsubscribe: