skip to content

In Flutter, what does log() from dart:developer give you over print(), and how do you read its output in DevTools?

level: middleimportance: should knowfreq 40%

answer

  1. structured event, not a line of text
  2. name, level, error, stackTrace
  3. level 0 to 2000, default 0
  4. JSON in error shows as data
  5. filter by level and text

basics

~20 s

log() from dart:developer emits a structured event with a name, a severity level (0-2000, default 0) and an optional error and stack trace, sent to attached tools. The DevTools Logging view lists and filters these events.

solid answer

~40 s

`log()` from `dart:developer` emits a **structured log event** rather than a line of text: `log(message, {time, sequenceNumber, level = 0, name = '', zone, error, stackTrace})`. The `name` groups messages by source, such as `shop.checkout`; `level` is a severity from 0 to 2000 modelled on `package:logging`'s levels; `error` and `stackTrace` attach the failure. The events go to tools attached over the VM service, so I read them in the DevTools **Logging view** or an IDE debug console, where I can filter by severity or text, hide noisy Flutter and Dart framework entries, and expand an entry's details. A handy convention: pass a `jsonEncode`d object as `error` and the Logging view shows it as data. Like any logging, anything sensitive still needs a debug guard.

code

dart · 12 lines
dart
import 'dart:convert';
import 'dart:developer' as developer;

void logCheckoutFailure(String orderId, Map<String, Object?> cart, StackTrace stack) {
  developer.log(
    'checkout failed for $orderId',
    name: 'shop.checkout',
    level: 1000, // 0-2000; higher is more severe
    error: jsonEncode(cart), // shown as a data object in the Logging view
    stackTrace: stack,
  );
}

go deeper

for a junior

Know that log() lives in dart:developer, takes a name and a level, and shows up in the DevTools Logging view.

for a middle

Explain the fields (name, level 0-2000, error, stackTrace, time, sequenceNumber), the JSON-in-error convention, and how to filter the Logging view by level and text.

for a senior

Show a logging discipline: stable names per subsystem, consistent levels, attached errors instead of string interpolation, and nothing sensitive in messages.

for a principal

Decide how development logging relates to production diagnostics: log() for tooling, a logging package with sinks for structure, and an error-reporting pipeline for release.

## What log() is `dart:developer` is the Dart library for talking to development tools. Its `log()` function emits a **log event**, a record with fields, rather than a line of text on stdout: ```dart external void log( String message, { DateTime? time, int? sequenceNumber, int level = 0, String name = '', Zone? zone, Object? error, StackTrace? stackTrace, }); ``` The API was designed to map closely to `package:logging`, so the fields line up with what a logging package records. ## The fields | Parameter | Meaning | |---|---| | `message` | the text of the entry | | `name` | the source of the message, for example `shop.checkout`; used for grouping and filtering | | `level` | severity, a value between 0 and 2000, default 0; higher means more severe, following `package:logging`'s `Level` values | | `error` | an error object, or by convention a JSON string with app data | | `stackTrace` | the stack trace for the error | | `time`, `sequenceNumber` | a timestamp and a monotonically increasing number | | `zone` | the zone that emitted the entry | ## Where the events go The events travel over the **Dart VM service** to attached tools, instead of being written to stdout the way `print` is. You read them in: - the **DevTools Logging view**, which shows them alongside other runtime events; - your IDE's debug console when the app runs under its debugger. By default the Logging view shows garbage-collection events from the Dart runtime, Flutter framework events such as frame creation, `stdout` and `stderr` from the app, and your custom log events. Useful controls: 1. **Filter by severity**, so only warnings and errors remain. 2. A **text filter** that also matches metadata such as the log name. 3. **Toggles to hide noisy Flutter and Dart logs**, leaving your own. 4. A **details pane** for the selected entry, switchable between raw text and JSON, with search. 5. A **retention limit** setting and a **Clear logs** button. ## Passing data with an entry The Flutter docs describe a convention: `jsonEncode` the object you want to inspect and pass the string as `error`. The Logging view then renders it as a data object in the details pane, which beats squeezing a map into the message text. ## log() compared with print and debugPrint - `print` and `debugPrint` produce **unstructured text**: no name, no level, no attached error. They are fine for quick traces. - `log()` produces **structured entries** you can filter and expand, which pays off as soon as more than one subsystem is logging. - None of them is a production logging solution by itself: in release builds there is no VM service for `log()` to reach, while `print` still writes to the device log. Production diagnostics belong to an error-reporting pipeline. ## Practical habits - Give every subsystem a stable `name` (`auth`, `payments.gateway`) so filters work. - Use levels consistently, so filtering by severity means something. - Attach `error` and `stackTrace` instead of interpolating them into the message. - Keep tokens and personal data out of messages; logs travel further than you expect.

  • Why pass jsonEncode(data) as the error argument of Dart's developer.log() instead of putting it in the message?
    The DevTools Logging view interprets a JSON-encoded `error` value as a data object and renders it in the entry's details pane, where you can expand fields. Interpolated into the message, the same data is a long, flat string that is hard to read and search.
  • What does the DevTools Logging view show besides your own dart:developer log() entries?
    Garbage-collection events from the Dart runtime, Flutter framework events such as frame creation, and the app's `stdout` and `stderr`. Toggle filters can hide the noisy Flutter and Dart entries so your own logs stand out.

saying these in an interview costs you the question

  • log() from dart:developer is just print() with a different name.
  • The level parameter of log() is an enum with only info, warning and error.
  • log() entries are sent to a remote logging service in release builds.
  • The DevTools Logging view shows only messages you logged yourself.
  • Attaching error and stackTrace to log() throws the error.