Robot Service Logging: Exception Trace and Current Stack

Robot Service Logging can include both exception information and a current stack description, but those attachments answer different questions. Python's logging documentation distinguishes exc_info from stack_info explicitly. A repair intake should preserve that distinction before calling every multiline block an exception traceback. This article reads Python 3.14 primary documentation and a hypothetical attachment. It executes no program, changes no logging configuration, and diagnoses no robot fault.

Exception information follows exception handling context

The official logging reference explains that exc_info adds exception information when its value is not false. It can use an exception tuple or exception instance, or obtain information through the documented current-exception mechanism. The same reference contrasts exception frames that have unwound while searching for handlers with the current stack used by stack_info.

A hypothetical service attachment may contain an error message followed by exception frames. The reviewer should ask which retained record and logging path produced that block. The presence of a formatted exception is not enough to identify a failed mechanical component. Its software context and the equipment's actual observations remain separate evidence questions, neither of which this article answers.

Current stack information can exist without an exception

The logging reference says that stack_info adds stack frames in the current thread up to and including the logging call. It can be requested independently of exc_info, including when no exception has been raised. This makes a practical difference when a contributor labels an ordinary diagnostic stack block as proof that an exception occurred.

In a fictional intake, the author may have included a stack description to show how execution reached a logging point. That is a different documentary purpose from retaining frames associated with an exception. Do not turn the similarity of multiline formatting into an equivalence of meaning. Ask for the block's origin and preserve any supplied logging options without rerunning the application.

Use the traceback reference to retain object identity

The official traceback module reference describes print_exception in terms of exception information and traceback entries. Its print_stack entry describes stack entries beginning from the invocation point, with an optional frame argument. These are separate reference entries with distinct inputs and purposes. Their existence reinforces the need to identify the actual source of a supplied block.

The reference also documents limits on how much is printed. An excerpt containing only some frames should retain that excerpt status. This article does not infer that missing lines mean no earlier call existed, and it does not reconstruct a full stack from a screenshot. A contributor's actual formatting and truncation choices need their own explanation if completeness is material to a review.

Write a repair note around the evidence actually supplied

A useful hypothetical note can name the application and Python version, the captured log artifact, the kind of frame information, and known excerpt limitations. It can then ask a precise follow-up: is this exception context, a current-stack diagnostic, or both? If the source is not supplied, leave that distinction unresolved rather than giving the block an unsupported label.

The logging reference also distinguishes stacklevel, which affects the caller information placed in the LogRecord, from stack_info. An option with a similar name is not automatically the switch that adds a complete stack block. A summary should keep those names intact so a later reviewer can connect the explanation to the correct documented behavior. No option values are recommended here.

A later correction can concern the intake wording without changing the underlying record. If a contributor relabels a block, retain the original artifact and identify the reason for the new description. If a newly captured artifact is supplied instead, it has a different capture context. Do not use that later record to imply that an earlier attachment originally contained information that was absent.

The logging reference describes exception() as adding exception information and says it is intended for use from an exception handler. That entry is another source identity worth retaining if a contributor names it. It does not imply that every ERROR-level record carries a traceback or that every stack block came from that method. Keep the method name, severity label, and actual supplied frame information as separate fields in a review note.

Thread context matters as well. The stack_info description refers specifically to the current thread. A block from one thread should not silently be described as the complete call state of all threads in a robotics application. This article has no thread inventory and does not infer what any unrecorded worker was doing.

The original illustrations compare documentation roles and show no real stack frames, file paths, customer data, or device error codes. Additional context is available in the robot service documentation section and related resources section. Distinguishing exception traces from current stacks keeps the intake specific enough to review while leaving root-cause findings attached to actual investigation evidence.