| Author |
Message |
|
| rpettit at vailsys.com |
 Posted: Thu Apr 03, 2003 4:56 pm |
 |
|
|
Guest
|
On Thu, Apr 03, 2003 at 11:07:34AM +0200, Ulf Wiger wrote:
> Remember that Erlang was designed for environments where
> "resetting" is probably a more correct description than
> "crashing" -- the program always has to bounce back,
> preferrably without the external users noticing.
Of course. Though C/C++ processes which are started out of inittab (Solaris)
or started via daemontools do "bounce back", it can hardly be argued that the
external user wouldn't notice  .
> I think the idea of having defensive interfaces wherever
> human (or otherwise external) input is involved is a good
> thing, but internal components should assume that the users
> of the interface have RTFM and use the component properly.
> In any event, misuse of the component should lead to
> distinct failures, not mystical semi-correct behaviour.
Agreed. Out of curiousity, if you were to write a C/C++ application (I know,
it's too gruesome to think about), would you follow the same strategy? That
is, would you NOT check for NULL, etc, in cases where you just should not
be passed NULL? How about in an application comprised of distinct processes in
a chain which could die and be reborn without the entire application crashing?
Of course such a system is far _inferior_ to the OTP equivalent, I am just
curious. And I think it goes without saying that referencing a NULL pointer
in code that is not defensive will not lead to semi-correct behaviour, but
rather a very distinct failure. Of course referencing a non-NULL pointer
which points at a region of memory the author was not aware of is another
story altogether, so perhaps this whole argument is mute (another win for
Martin's argument with "LM").
> I think it's a mistake to confuse the two, but also always
> try to write my code in the same way in both cases. Error
> handling in the external interface is taken care of by
> catching exceptions at the top and interpreting the
> exception information into a human-readable error message.
> This top layer will have different semantics depending on
> the nature of the interface (window-based GUI, command line,
> HTML pages, ...).
Agreed. Though I think a similar strategy could be taken with C++ and
exceptions. Of course being completely non-defensive in the core of the
application could lead to segfaults (though I believe even these exceptions
can be caught, though the process is doomed after the exception handler
returns, IIRC).
-Rick
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| matthias at corelatus.se |
| Posted: Thu Apr 03, 2003 7:19 pm |
|
|
|
Guest
|
Rick Pettit writes:
> Agreed. Out of curiousity, if you were to write a C/C++ application
> (I know, it's too gruesome to think about), would you follow the
> same strategy? That is, would you NOT check for NULL, etc, in cases
> where you just should not be passed NULL? How about in an
> application comprised of distinct processes in a chain which
> could die and be reborn without the entire application crashing?
not checking for "NULL" isn't quite the same as the usual erlang
approach. The usual erlang approach is to use pattern matching to
force an abort in many cases where something unexpected happens, e.g.
{ok, S} = gen_tcp:connect(Host, Port, Options),
...
you can't really write that naturally in C, I find myself forever
writing
sock = connect(...);
assert(sock);
Is that defensive programming? Not really, IMO. PERL has an idiom
which is somewhat like Erlang, btw: f() || die
Matthias
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| rpettit at vailsys.com |
| Posted: Thu Apr 03, 2003 7:56 pm |
|
|
|
Guest
|
On Thu, Apr 03, 2003 at 01:28:43AM -0800, Thomas Lindgren wrote:
> Misspelled variables are caught by the compiler. (Esp.
> if you use warn_unused_vars.)
Ok. Can't remember the details on what was misspelled (i.e. variable or
function), so please excuse that remark.
> * The main benefit of Erlang, Lisp, Prolog, SML and so
> on is _type_safeness_: there is no way that you can
> accidentally confuse one value's type with another.
> This (along with GC and pureness) gets rid of the
> majority of errors.
>
> (This is also known as 'strong typing', not to be
> confused with 'static typing'.)
Ah, thank you for clarifying.
> * Finally, static typing in the sense above is
> prescriptive: it will reject programs that are okay
> because it can't prove they are (e.g., heterogenous
> lists were rejected for a long time; not sure about
> whether it's handled well these days). This may mean
> you have to 'code around' the problem, though a static
> typing guy might say you are removing a latent bug.
>
> Also, the programming language designers will have to
> restrict programs to enable checking (e.g., receive
> ... end is hard to check in its current form, since
> any process can potentially send to any process, as is
> hot code loading, for obvious reasons).
Agreed.
> To summarize:
>
> Personally, I find that static typing in its current
> form adds little value to my Erlang programming.
> Errors due to type mistakes do appear, but not so
> frequently as to make it a major problem. The
> consequences are exceptions, not core dumps or quiet
> madness, so debugging is easier than in the C++ case.
Quiet madness is certianly no good. As for core dumps, I personally find
them pretty easy to make use of. If you know how to run a backtrace and
work with thread info, etc, you can pretty quickly find out what went
wrong and in what thread. I will not argue though that this is easier
than debugging Erlang code (in fact I cannot, since as I have said before
I am no Erlang/OTP HaXoR ;-)
> (An opinion: Making Erlang even easier to test would
> probably be more pragmatically beneficial than adding
> static typing.)
Seems to make sense. Thank you for clearing some of this up for me.
-Rick
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| vances at motivity.ca |
| Posted: Thu Apr 03, 2003 7:56 pm |
|
|
|
Guest
|
There are good reasons for writing defensive C code. You need
to check for memory bounds mainly. If you didn't you'd have
plenty of the sort of flaws which make for CERT advisories.
I don't extend the Erlang "let it fail" philosophy to my C
driver code. Personally I consider this interface to be
external and code the C node to validate the input.
-Vance
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| rpettit at vailsys.com |
| Posted: Thu Apr 03, 2003 8:19 pm |
|
|
|
Guest
|
On Thu, Apr 03, 2003 at 09:18:46PM +0200, Matthias Lang wrote:
> not checking for "NULL" isn't quite the same as the usual erlang
> approach. The usual erlang approach is to use pattern matching to
> force an abort in many cases where something unexpected happens, e.g.
>
> {ok, S} = gen_tcp:connect(Host, Port, Options),
> ...
>
> you can't really write that naturally in C, I find myself forever
> writing
>
> sock = connect(...);
> assert(sock);
>
> Is that defensive programming? Not really, IMO. PERL has an idiom
> which is somewhat like Erlang, btw: f() || die
Not sure I completely agree here. Checking for NULL _IS_ checking for the
unexpected (you just do it more often in C/C++). In both cases you expect the
connection to be established, and in both examples you assert that it is.
Pattern matching to force an abort (at least in this case) is just syntactical
sugar for aborting on failed assertion.
If aborting when something unexpected happens is not defensive programming, then
perhaps I have a more fundamental misunderstanding.
-Rick
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| matthias at corelatus.se |
| Posted: Thu Apr 03, 2003 9:18 pm |
|
|
|
Guest
|
Rick Pettit writes:
> On Thu, Apr 03, 2003 at 09:18:46PM +0200, Matthias Lang wrote:
> > not checking for "NULL" isn't quite the same as the usual erlang
> > approach. The usual erlang approach is to use pattern matching to
> > force an abort in many cases where something unexpected happens, e.g.
> >
> > {ok, S} = gen_tcp:connect(Host, Port, Options),
> > ...
> >
> > you can't really write that naturally in C, I find myself forever
> > writing
> >
> > sock = connect(...);
> > assert(sock);
> >
> > Is that defensive programming? Not really, IMO. PERL has an idiom
> > which is somewhat like Erlang, btw: f() || die
> Not sure I completely agree here. Checking for NULL _IS_ checking for the
> unexpected (you just do it more often in C/C++). In both cases you
> expect the connection to be established, and in both examples you
> assert that it is.
I do not think the explanation of how to approach error handling in
the programming recommendations is a good one*. Neither do I think
"defensive programming" is a good term for it. I ripped off Joe's
improved explanation in the FAQ (question 10.15)
http://www.erlang.org/faq/
The key is separating error detection and error handling. The talk
about "defensive" is a distraction. (Aside: I can't find a good
definition of the term. The first 10 links googles gives me all lead
to useless essays calling everything from descriptive variable names
to exceptions "defensive programming". Is it one of those things
everyone feels is a good idea and nobody knows exactly what it is?)
There are two problems with the above style in C. One is that it makes
the code longer. The other is that error handling becomes all or
nothing. If the socket does not connect, the entire program will
die, unless the program is structured into several unix processes.
Some long-running C programs could actually work reasonably well
with such a model, one example is a web server which fork()s for each
new connection.
In Erlang, there are two main ways to handle errors
non-locally. Exceptions and supervision. I think of the difference as
being a matter of where you draw your boundary. Exceptions draw the
boundary through a certain level of the stack. Supervision draws it
around a process. I use both approaches in our systems, they're
useful in different situations. But the situations where supervision
is useful seem to outnumber the situations where exceptions are useful
20 to 1.
Matt
* Why did an april fools post contain real criticism? I figured the
hoax would work best if started plausibly and then ramped up the
implausibility.
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| eleberg at cbe.ericsson.s |
| Posted: Fri Apr 04, 2003 11:59 am |
|
|
|
Guest
|
> On Wed, 2 Apr 2003 13:18:15 -0600
> Rick Pettit <rpettit_at_vailsys.com> wrote:
>
(hope this is the correct person getting the attribution)
> > Well yes, unless the C/C++ application loading the shared object
> > (which in turn requires runtime linkage) does so over and over again
> > (i.e. loads .so, then later unloads and reloads NEW .so, and so on).
i used shared libraries like this to hot swap code for a network server:
1 install the new lib.
2 send SIGINIT to the process.
when the main thread received SIGINIT it would come out of the listen()
and do a fork().
the parent would wait for all worker threads connections to close. then
it would exit.
the child would re-read the config file and then start a new
listen().
should i explain more, or is this (including any oversights) sufficient?
bengt
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| garry at sage.att.com |
| Posted: Fri Apr 04, 2003 7:07 pm |
|
|
|
Guest
|
James Hague <jamesh_at_Volition-inc.com> wrote:
> Yes, I agree with that. I've wondered how Erlang would be with Python and
> Haskell's "significant whitespace" as an alternative to all the commas and
> semicolons (ah, the endless debates that would start).
that would be a thing of beauty.
----
Garry Hodgson, Senior Hacker, AT&T Labs
"You've been telling lies so long
Some believe they're true
So they close their eyes to things
You have no right to do"
--- Steppenwolf
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| wuji |
| Posted: Thu Aug 16, 2012 8:12 am |
|
|
|
User
Joined: 10 Aug 2012
Posts: 654
|
apartment complex in Deerfield Beach, Fla. One boy poured rubbing rubbing imitation designer *beep* rubbing alcohol on Brewer, and another flicked a lighter, setting
ablaze.Brewer survived the attack by jumping into a nearby pool, pool, imitation designer *beep* pool, but not before second- and third-degree burns covered nearly
of his body.While Bent played no physical role in the the [h4]cheap Ralph Lauren[/h4] the attack, the prosecution accused him of orchestrating it in
of cold-blooded revenge against Brewer. In closing arguments, Assistant State State cheap designer *beep* State Attorney Maria Schneider stressed to the jury the disputes
Bent and Brewer in the day leading up to the the [h3]jordan 6 olympic 2012[/h3] the attack.The previous day, Brewer's parents reported Bent to the
for allegedly attempting to steal a family bicycle. Brewer said said imitation designer *beep* said he stayed home from school on Oct. 12 fearing
retaliation by Bent, who he testified Thursday was targeting him him knockoff designer *beep* him because he refused to buy drug paraphernalia from Bent.Denver
17, who is serving eight years in prison for pouring pouring jordan 6 olympic pouring the alcohol on Brewer, testified Wednesday that Bent offered |
|
|
| Back to top |
 
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
