> I think hard exceptions (like failed asserts in C) are fine for things
> that are obviously programmer error (like wrong number or types of
> arguments).  in C these are caught by the compiler, but we don't have
> strict type checking in candor.  We need some sort of hard assert for this.
>  I could build it into the candor.io library and implement it in C++. It
> would be nice if I had a way to get the stack trace, or at least the line
> that threw the assert.

> But the other class of errors that you don't want crashing your server are
> invalid user input.  The way libuv (The C library behind nodejs and
> candor.io) handles these errors is to return a non-zero status on any
> function call that potentially can throw an error.  For async functions,
> there is a status property in the callback.  It's the responsibility of the
> programmer to check for this status code and them pull the actual error
> message out of libuv using the error API.

> I've done something like this for candor.io.  It's not pretty, but seems
> to work ok.  The only sticky point is sync functions that return a value.  
> Where do I put the status code?  In lua this is done with multiple return
> values, but I don't think that's a feature we want to add to candor (as
> much as I love it).

> throw = (err) {

>   global.prettyPrint(err)

>   global.exit()

> }

> // Used to emit on errors when libuv badness happens

> check = (status) {

>   if (status) {

>     throw(require('uv').​lastError())

>   }

> }

> ServerPrototype = {}

> ServerPrototype.listen = (self, port, host, callback) {

>   if (!host) host = "0.0.0.0"

>   check(self.socket:bind(host, port))

>   check(self.socket:listen(​128, (status) {

>     check(status)

>     client = new ClientPrototype

>     socket = Tcp.create()

>     client.socket = socket

>     check(self.socket:accept(​socket))

>     self.onConnection(client)

>     check(socket:readStart((​nread, chunk) {

>       if (nread == -1) {

>         err = require('uv').lastError()

>         if (err.name == "EOF") {

>           client.onEnd()

>         } else {

>           throw(err)

>         }

>         return

>       }

>       if (nread > 0) {

>         client.onData(chunk)

>         return

>       }

>     }))

>   }))

> }

> On Fri, Mar 23, 2012 at 11:57 AM, Fedor Indutny <fe...@indutny.com> wrote:

>> Bradley,

>> Exceptions are good, but I'm considering Candor to be more like C, than
>> C++.

>> As I know C works fine w/o exceptions, I'm open to introducing some sort
>> of `abort()` instruction, which will leave candor into C++ land.
>> Feedback is welcome!

>> Cheers,
>> Fedor.

>> On Fri, Mar 23, 2012 at 9:29 PM, Bradley Meck <bradley.m...@gmail.com>wrote:

>>> In situations where you are extending a function/method in a way that
>>> could cause a need to throw an exception in other languages what is the
>>> idea for how to handle this?

>>> ```candor
>>> Rect = {
>>>   initialize: (self, w, h) {
>>>     self.w = w
>>>     self.h = h
>>>   }
>>> }

>>> Square = new Rect
>>> Square.initialize = (self, w, h) {
>>>    if (w !== h)
>>>       // ?
>>>    Rect.initialize(self, w, h)
>>> }
>>> ```

>>> This example is naive, but it will come up in cases where an interface
>>> that originally did not have exceptions / didn't need callbacks to notify
>>> exception would suddenly need exceptions. Right now the only way to halt a
>>> large nesting of calls seems to have every return checked.