+Fuchsia API CouncilThe reason we prefer to use error codes rather than more elaborate error data is that the elaborate error data becomes ABI surface for the platform. In thinking about this use case, I would try to find a way to provide more detailed error information to the developer without making that error information part of the system ABI. That's why the rubric suggests logging as a mechanism: it's a way to communicate with developers that doesn't expand the system ABI.AdamOn Wed, Mar 3, 2021 at 8:35 PM 'Adam Lesinski' via fidl-dev <fidl...@fuchsia.dev> wrote:Hi FIDL team,In Component Framework, we have several FIDL protocols that return our domain-specific error code when a failure occurs. We find that the error code is not enough to debug thorny issues. For instance, the implementor of the protocol (eg a ComponentResolver) is being called by component_manager, and the implementor returns a failure. Detail information of the failure is not available in the logs because something in the system may be broken and logs aren't coming back from the implementor.Is there an existing pattern that offers richer error information?I was thinking of blending the fuchsia.io approach with regular error codes, where the protocol would receive an optional channel as an argument, on which an event would be sent with detailed error information. The protocol method would still return an error code, which would be used to determine if the passed in channel should be listened to.Your guidance would be most appreciated.Adam--
All posts must follow the Fuchsia Code of Conduct https://fuchsia.dev/fuchsia-src/CODE_OF_CONDUCT or may be removed.
---
You received this message because you are subscribed to the Google Groups "fidl-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fidl-dev+u...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/fidl-dev/9aa6ff2b-d8f6-4e39-bbe0-9090987d8805n%40fuchsia.dev.
You received this message because you are subscribed to the Google Groups "api-council" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-council...@fuchsia.dev.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAP%3D28cfwztchvswBk3HYDh4K8RDcmdY_09kfazDReaPd0bX20A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAP%3D28cc4z4MAiYbBZQYMAUB%3Dt7nLTcKe%3Dy4c7s9snO4ehQdxdQ%40mail.gmail.com.
Here's a more concrete version of that idea:When I work on a piece of software, I often set my logger to filter log messages to only those with my component's tag (i.e., fx log --tag <foo>). If a service my component uses generates an error, I won't see that because the log will have the tag of the component that recognizes the error instead of the tag of the requestor. What if there was a way to cause that error message to be displayed even when the developer is filtering on their own component's log tag?
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAP%3D28cfnG-Dq3FKR7ZN8mC2vhy%3D8X_cWPrRLUEh-zg9kzLKnKQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAP%3D28ccP1CoS_gqiYkwK83EHpCvd8FJv%2BtmGamHGGyBTUBMY-A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAN8c-rWTeT1KkeMZ%2BWLdKtR1x8zffqW0HutbTLFKm9WBeb%3D%2BrQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAK0PkCFmeHfWdQkAJkVi7yRWRPhzRSwgasXK5D2DQd_OSXr3gQ%40mail.gmail.com.
Following IPCs with debuggers is hard. The most success I've had was to anticipate where the other end of the IPC will land, attach to that process and prepare a breakpoint there, and then keep tracing the flow. I would often make mistakes, lose track of the control flow, and have to start all over again. It was so painful that I developed the habit of keeping a text file open where I'd jot down breadcrumbs and other notes on my progress.On Thu, Mar 4, 2021 at 10:23 AM Carlos Pizano <c...@google.com> wrote:In other systems we use debuggers. They were developed to exactly provide the context necessary to understand errors.-cpuOn Thu, Mar 4, 2021 at 9:56 AM 'Chase Latta' via api-council <api-c...@fuchsia.dev> wrote:Would it be possible for us to include extra metadata in our SDK which can be consumed by ffx to help developers diagnose these problems? For example, when a fidl library is written the developer can include some metadata file that says what error codes can be returned for individual methods. We can then update ffx to have a command like `ffx error describe fuchsia.io.foo 37` which prints out the developer defined log statement. We could add a watch type function as well which automatically looks up this information for you.On Thu, Mar 4, 2021 at 9:50 AM 'Adam Barth' via api-council <api-c...@fuchsia.dev> wrote:What if we improved our developer tools in some way? Conceptually, rather than returning the error information to the software that made the request, we should somehow find a way to return the error information to the developer of that software. For example, what if there was a way to associate a log message containing error information with the request that triggered the error in a way that our developer tools understood and presented to the developer in some useful way...Adam
Could we teach zxdb to do all of that automatically (and correctly)? I'm imagining in addition to step into, step over, and step out, we could have a "step through" that advanced to the point at which the next zx::channel message sent by the current thread was received by another process in the system.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAP%3D28cdcgMWchDCPDWVNEb4yMcCOf9WKryd2OqF9%3DDwh0oRRhg%40mail.gmail.com.
Could we teach zxdb to do all of that automatically (and correctly)? I'm imagining in addition to step into, step over, and step out, we could have a "step through" that advanced to the point at which the next zx::channel message sent by the current thread was received by another process in the system.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAP%3D28cdcgMWchDCPDWVNEb4yMcCOf9WKryd2OqF9%3DDwh0oRRhg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAOsj%2BYkgEOtMtCrcEQ5TXgYohgK8w1_qE4r3MGdSsQ54WE_2yw%40mail.gmail.com.
On Thu, Mar 4, 2021 at 10:54 AM 'Adam Barth' via api-council <api-c...@fuchsia.dev> wrote:Could we teach zxdb to do all of that automatically (and correctly)? I'm imagining in addition to step into, step over, and step out, we could have a "step through" that advanced to the point at which the next zx::channel message sent by the current thread was received by another process in the system.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CACr%3D8_Ov%2B2YGu%3DD7%3DmN1SiMUuq4LY2ihKvZ58Hz7hj1MCgO0DA%40mail.gmail.com.
On Thu, Mar 4, 2021 at 10:54 AM 'Adam Barth' via api-council <api-c...@fuchsia.dev> wrote:Could we teach zxdb to do all of that automatically (and correctly)? I'm imagining in addition to step into, step over, and step out, we could have a "step through" that advanced to the point at which the next zx::channel message sent by the current thread was received by another process in the system.IMO, this would be greatly aided by a context ID in the message itself. E.g. zxdb could 'contact the recipient' ahead of time (err, after the user asked to "step through" and before actually sending it and set a conditional breakpoint in that process for when message context ID == NNNN.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAOsj%2BY%3Dq6Mvt56-ZjeR9b9aVtxOW1qar3m0V%2BtuevtSaAGgOrg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/fuchsia.dev/d/msgid/api-council/CAPYFHW3VZKdnAqcPRRRVRjU1%2BPE6uY-SdMV-nc9aU%2BpRKAnWmw%40mail.gmail.com.
On Thu, Mar 4, 2021 at 10:57 AM Seth Ladd <seth...@google.com> wrote:
On Thu, Mar 4, 2021 at 10:54 AM 'Adam Barth' via api-council <api-c...@fuchsia.dev> wrote:Could we teach zxdb to do all of that automatically (and correctly)? I'm imagining in addition to step into, step over, and step out, we could have a "step through" that advanced to the point at which the next zx::channel message sent by the current thread was received by another process in the system.
Yes, though it will require some tricky kernel and library cooperation. This feature is perennially on the wish list but the debugger is currently not staffed enough to be able to do this type of difficult cross-functional project.
Thanks for all your replies everyone! This is obviously a rich topic with plenty of opinions and potential solutions.Unfortunately I was seeking more of an O(days) solution and a current best practice recommendation.As I mentioned in the beginning, logs are useful but in my situation I can't always rely on there being logs (aside from the kernel log). Granted, this may be unique in that the only people experiencing this are people working on early boot.I think for my situation I DO want some error details to be part of the ABI. There's a balance between too little information and too much, but I think erring on providing very little has its own price: PEER_CLOSED for every error case.First, instead of reusing an existing Error enum, I think using a domain-specific error will allow me to represent errors better, while still just using an integer code to do that.
Second, if I need to wrap a downstream cause of the error, I think what Yifei mentioned is a decent approach: return my own union that represents the success and error states (like Result in Rust), which allows me to place more error information (part of the ABI) into a table in the error variant.
Ack that Adam is looking for a short-term solution, but I wanted to also note that Forensics is funding a Q2 project that allows fidlcat and zxdb to be used at the same time. From what I understand, this project will get us closer to being able to step across channels.