Ferreteria/v0.6/clade/Sys/Diag

namespace: Sys\Diag

Subpages
Break Break/Native Break/Native/@code Break/Native/@code/cur/2026/06/01 Break/Native/Legacy Data Data/Error/Card Data/Stack Data/Stack/Card Data/Stack/Card/@code Data/Stack/Card/@code/2025/06/29 Data/Stack/Deck Data/Stack/Deck/@code Data/Stack/Deck/@code/removed Util/Reflect Util/Reflect/@removed Util/viewer/Inspector

Pages

• aux - namespace
• Break - clade-family
• Data - namespace
• Logger - clade family
• styles - namespace
• Util - namespace

History

• 2024-08-23 Rewriting "Problem" class-structure from scratch as "Break".

Notes/Thinking

2024-08-24

It's not yet clear whether Throwable and Error actually have anything in common that isn't also in Break, but I'm going to put them in a hierarchy under Native for conceptual clarity and also just-in-case.

The main functional difference between a (native) Throwable (class) and a native error (functions / global handlers) is the fact that Throwables can be scoped within the code (using try/catch). I'm going on the theory that things will be moving increasingly towards the Throwable mechanism, and will refer to the function-based native error stuff as "Legacy".

2024-08-23

• [WFe\SD]Problem\Native\iThrown (a [WFe\SD]Problem\iNative)
  • has a [WFe\SD]Problem\Native\iError.
  • which is a [WFe\SD]Problem\iNative...
  • This is a problem.

Reworking

• Every type of Problem will need a Stack, so it does make some sense to start there.
• Why isn't Problem a descendant of Stack ([WFe\SD]Data\Stack\*Deck)? PROBABLY A TODO.
• Throwable does have Error information, but it's not wrapped separately.
  • So it makes sense to have a common interface for handling the Error information.
  • ...and maybe a common data (xfer) object, for handling the details?
  • ...but it would be initialized differently, depending on whether we have a (native) error or a Throwable.
  • ...and we want to avoid confusing future -me- coders by having the same class initializable in both ways.