Error handling

[emil14]

Motivation

We don't have methods in FBP so we don't have behaviour-based interfaces for data, but we can use data structure itself as an interface. I.e. we can have err (convention/std-type?) struct instead of just string. Motivation is adding "stacktrace" (it's more like path than stack trace because there's no stack (besides go's native stack)) to avoid go's tedious errors wrapping.

Possible solutions

error {
  trace []str
  msg str // <- we remember only last message
}

msg str // <- we remember only last message

Maybe there must be a way to wrap messages like we do in go?

Problems

Tracing must be implemented - #94

[emil14]

Go-like

error {
  err? error
  s str
}

Figure out usecases

[emil14]

Automatic wrapping

Avoid go-like Errorf wrapping and use builtin tracing. Should all messages have have trace? Should we have wrap component?

Optional wrapping

We can some additional data by wrapping instead of imitating stacktrace

[emil14]

Error creator component

[emil14]

https://docs.rs/stacktrace/latest/stacktrace/

Rust uses Result<T,E> type so the error itself is not a predefined interface but instead any possible type

It might be useful to provide an ability to use different kinds of errors

This though must be carefully thought about

[emil14]

My current vision is that

1. Trace must be there "for free" (user should not do anything to get it, like in e.g. Python and not like in Go/Rust)
2. It could be good idea to implement tracing everywhere i.e. for all messages, then this issue becomes just a specific case of that machinery
3. But it's not clear of such trace could be generated by network/traffic manager (runtime connector)

3 must be investigated

[emil14]

#94 (comment)

How to combine with this? (Problem about mapping messages onto trace levels)

[emil14]

Solution

1. Implement Messages tracing #94
2. Implement errWrap(err error, msg str) error component that will:

• Create new message with the given msg
• New message will point to the given err as a parent (or child, whatever)
• ...
• Profit! First/last trace element in each message is relates to msg (because of immutability of messages)

[emil14]

If tracing start from the place where error is occurred wouldn't it be a problem to keep track how we got there?

---

Maybe component like errors.Wrap could wrap the needed information?

[emil14]

Problem with automatic wrapping and loops

If anytime message is traveling from one port to another we wrap it with trace, then looped component will add big amount of trace