SourceHorizon / logger

Small, easy to use and extensible logger which prints beautiful logs.
https://pub.dev/packages/logger
MIT License
197 stars 33 forks source link

Reading .ans files & Flutter system errors to log #47

Closed hsynksahin closed 10 months ago

hsynksahin commented 10 months ago

I made my application logs to file, it working just fine but I have several questions:

First

What do I do with this text file? I mean when you try to read it in a normal text reader like Notepad++ or Vs Code you will se some 'ESC' or color chars thats not working. Is there any extensions kinda thing (that I searched but couldn't found) that reads that ansi color and changes the line's color acourding to it? Is there a way to convert those 'ESC' and '[0m' (end of line I guess) chars to something else automaticly.

Log file view ![Screenshot 2023-11-02 113822](https://github.com/SourceHorizon/logger/assets/29236412/5825e3fe-9d1b-468a-9175-937e0bf3453c)

Second

Can I log the systems/flutter's logs to the same file too? If there will be an other error like widget cant fit to the screen or something, the flutter it self would log it to the console but the file output wont contain it. Also in release mode how to log these logs to the file.

Note: I know this is most likely a stackoverflow question but im asking here bc maybe someone tryed to log the system logs to this package before. If there is no other solution than logging to seperate file you can ignore this question.

Bungeefan commented 10 months ago

First

Hi, I am currently not aware of any extensions which would add ANSI color support to any of the editors you mentioned. However, please update us if you discover one.

The terminal command less seems to support it, however, it is only available on Linux and not on Windows (at least out-of-the-box). Another solution would be to disable the colors in the PrettyPrinter or switch to another printer.

Second

For your second problem, you can add callbacks to the system/flutter error handlers. The following code snippets attach your logger to the error handlers while still trying to preserve the default behavior (e.g. printing it in the console).

This handler logs all uncaught exceptions, and return false signals that the caller should still use the fallback logic.

// Uncaught Exceptions.
PlatformDispatcher.instance.onError = (exception, stackTrace) {
  MyApp.log.f(
    "Unhandled Exception",
    error: exception,
    stackTrace: stackTrace,
  );
  return false;
};

Docs:

This callback must return true if it has handled the error. Otherwise, it must return false and a fallback mechanism such as printing to stderr will be used


This handler logs all "widget" rendering errors, while still calling the default presentError handler.

// Rendering Exceptions.
FlutterError.onError = (details) {
  FlutterError.presentError(details);

  MyApp.log.f(
    details.exceptionAsString(),
    error: (kDebugMode
        ? details.toDiagnosticsNode().toStringDeep()
        : details.exception.toString()),
    stackTrace: details.stack,
  );
};

Docs:

You can set this to your own function to override this default behavior. For example, you could report all errors to your server. Consider calling presentError from your custom error handler in order to see the logs in the console as well.

hsynksahin commented 10 months ago

Thank you for your answer @Bungeefan, I really love this answer. I will notify you if I can find something useful about ansi colors, for now the file is readable so it will do it.

About why I dont want to change PrettyPrinter is that I wrote a Decorator for the FileOutput that both outputs to a file and the console. So I wanted that colors on my console.

Here is what I have as the output, if you want to check:

import 'package:logger/logger.dart';

class FileOutputDecorator extends FileOutput {
  FileOutputDecorator({
    required super.file,
    super.encoding,
    super.overrideExisting,
    bool consoleLog = false,
  }) : console = consoleLog ? ConsoleOutput() : null;

  ConsoleOutput? console;

  @override
  void output(OutputEvent event) {
    super.output(event);
    console?.output(event);
  }
}

And Im using it like

FileOutputDecorator? logOutput;
// initializing logOutput here (if fails its null)
output: logOutput ?? ConsoleOutput(),

Again thank you for the answer, I guess thats should resolve my questions.

hsynksahin commented 10 months ago

There is a VS Code extention for both editing & previewing the ANSI coded file. Extensions ID: iliazeus.vscode-ansi work fine for me now.

In case anyone else wants to do the same thing what I do.

kostov commented 7 months ago

Does file-writer uses write-buffering? If yes, how to flush buffer to file?

Bungeefan commented 7 months ago

Hi @kostov, the FileOutput uses an IOSink to write its output, which AFAIK can be buffered (depending on the implementation/platform). In general, you are able to call flush() on an IOSink, however, there is currently no way to manually flush the internal IOSink in the logger, except when closing it via close().

kostov commented 7 months ago

@Bungeefan, thank you, will try to close() it before send log-file, then re-create.

kostov commented 2 months ago

will try to close() it before send log-file, then re-create.

returned to the project, made it as proposed -- works fine

hsynksahin commented 2 months ago

will try to close() it before send log-file, then re-create.

returned to the project, made it as proposed -- works fine

Im sending my log files to the server on a feedback case too. Never considered that I need to call close command. I tought the FileOutput automaticly flushes to the file. Did you test it without close comand ? Is there any lost on the logs ?

hsynksahin commented 2 months ago

Sry about the title misunderstanding btw. This issue was for my questions. May need to carry this to an other issue

kostov commented 2 months ago

Did you test it without close comand ?

No (I'm lazy :). But after fix all logs became fine, and before was not...

I tought the FileOutput automaticly flushes to the file.

I'm afraid this is not effective. I think all file operations (in common case) should be buffered by default.