[erlang-questions] Fwd: Must and May convention
Thu Sep 28 13:21:56 CEST 2017
A few more comments
All code might crash so you have to decide what to do.
I think of code as belonging to different categories:
a) Code that if is incorrect will totally screw up your system
b) Code that if it incorrect will screw up part but not all of your system
c) Code that if you restart it might work
d) Code that is in production so it should not crash
e) Code that is being developed so you expect the odd crash
It's part of the design to figure out which code should be in which
A few years ago, when I was helping build some pretty complex systems
we did this. What concerned me was the category a) code - this
is what I called the "error kernel" - a goal was to make this as small
as possible. This part was written by our most experienced programmers
and heavily checked.
Other code in the system had far less stringent requirements on quality.
For example, Internationalization. Error messages were in English, and we
modules to turn them into different languages.
This code was not failure-critical - the default strategy if the code failed
was "revert to English" - so this code was done by our "beginners"
Part of system design is isolating the error-kernel making it as small as
and getting it implemented by the best programmers.
All this supervision tree stuff is fine - but you do have to trust
that the code that implements supervision trees and gen_servers and so on
On Thu, Sep 28, 2017 at 12:48 PM, Roman Galeev <> wrote:
> > We could imagine an intermediate category of calls that are a sort of
> "pure RPC"
> Yeah, I've been thinking of something like that. Anyway, this 'pure RPC'
> notion could give enough clues to a developer, and to code analyzing tools.
> On Thu, Sep 28, 2017 at 12:39 PM, zxq9 <> wrote:
>> On 2017年09月28日 木曜日 12:32:32 you wrote:
>> > Interesting. Not so strictly speaking, some of the gen_server calls
>> that do
>> > not change its state may be seen as 'pure' albeit relying on messaging,
>> > a tool could probably figure out such calls automatically. And this
>> > definitely could help to figure out what' going on in a project.
>> Perhaps -- but you probably do NOT want a naked call there, because there
>> is no guarantee the process you called actually exists. Or is on the same
>> node. Or is calling some external resource not even related to Erlang to
>> figure out its response.
>> We could imagine an intermediate category of calls that are a sort of
>> "pure RPC", but the utility of this distinction may be pretty limited --
>> we can't (and shouldn't) know what is going on inside another process.
>> Anyway, it is worth exploring the idea, maybe. At the moment I'm looking
>> at a very limited goal: getting pure declarations to be a real thing. If
>> I had more time I would formally propose it and work on implementation --
>> but I have my hands full and a HUGE backlog of other, slightly higher
>> priority things I think will improve Erlang tooling at a more immediate
>> level of impact.
>> erlang-questions mailing list
> With best regards,
> Roman Galeev,
> +420 702 817 968 <+420%20702%20817%20968>
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions