5 ms·

Slight problem there, at least in Erlang; if A sends a message to B that causes B to crash, A doesn't know about it. A doesn't in any way see the error (though

Slight problem there, at least in Erlang; if A sends a message to B that causes B to crash, A doesn't know about it. A doesn't in any way see the error (though it may be restarted if part of the same supervisor, and it may timeout and crash if waiting for a response). So handling that message/not handling that message doesn't affect debugging; the top of your stack trace will be in B, regardless (and you may have a separate one at A if it times out waiting for a response from B, or if it's been linked to B such that it dies when B dies). Errors do not propagate except where you've said they should; i.e., by your supervision tree, or by explicit linking.

deleted 12y ago
[deleted]
EGreg 12y ago
No, B should log it along with the accumulated call stack, before crashing.
- lostcolony 12y ago
  In Erlang, B will log only what stack accumulated in B's process. Nothing from A's. That is - run() -> B = spawn(fun() -> receive_func() end), A = spawn(fun() -> send_func(B), io:format("A completed normally", []) end). send_func(Pid) -> Pid ! whatever. receive_func() -> receive _ -> throw(blah) end. You will receive a call stack listing only an error in receive_func. You will not have the anonymous function in B (due to tail call optimization) in the call stack, and you will not have the send_func in the call stack, at all, because that process completed normally; there was no error involved with it (a fact you can see by the io format call, which will be invoked just fine). A sent its message, and then printed something, and that's it. B's error does not relate to A; A might have a separate error (such as if I were to add a receive clause to send_func, expecting a response, that times out after a while), but that error is unrelated to B, and will create an entirely separate error in the logs, with an entirely separate call stack.
  - jacquesm 12y ago
    Sorry for posting that just before running out of the office. You are 100% correct. So the thing to do here is to isolate the message that caused the crash, that way you don't need to know what happened in 'A', you shouldn't have to know what happened in 'A'! If you do have to know what happened in A then you are using messages where you should have used function calls, after all a message should be context free once it leaves the sender. This may require some re-thinking of the concept of messaging, it is wrong to see a message as some kind of RPC mechanism, a message is a self contained package sent to a recipient that contains everything the recipient needs in order to process it and/or elicit a reply. Any other state should be elsewhere and should not be required at all to identify the cause of the crash. Getting this right can be quite tricky.

deleted 12y ago

[deleted]

EGreg 12y ago

No, B should log it along with the accumulated call stack, before crashing.

lostcolony 12y ago
In Erlang, B will log only what stack accumulated in B's process. Nothing from A's. That is - run() -> B = spawn(fun() -> receive_func() end), A = spawn(fun() -> send_func(B), io:format("A completed normally", []) end). send_func(Pid) -> Pid ! whatever. receive_func() -> receive _ -> throw(blah) end. You will receive a call stack listing only an error in receive_func. You will not have the anonymous function in B (due to tail call optimization) in the call stack, and you will not have the send_func in the call stack, at all, because that process completed normally; there was no error involved with it (a fact you can see by the io format call, which will be invoked just fine). A sent its message, and then printed something, and that's it. B's error does not relate to A; A might have a separate error (such as if I were to add a receive clause to send_func, expecting a response, that times out after a while), but that error is unrelated to B, and will create an entirely separate error in the logs, with an entirely separate call stack.
- jacquesm 12y ago
  Sorry for posting that just before running out of the office. You are 100% correct. So the thing to do here is to isolate the message that caused the crash, that way you don't need to know what happened in 'A', you shouldn't have to know what happened in 'A'! If you do have to know what happened in A then you are using messages where you should have used function calls, after all a message should be context free once it leaves the sender. This may require some re-thinking of the concept of messaging, it is wrong to see a message as some kind of RPC mechanism, a message is a self contained package sent to a recipient that contains everything the recipient needs in order to process it and/or elicit a reply. Any other state should be elsewhere and should not be required at all to identify the cause of the crash. Getting this right can be quite tricky.