On Wednesday, 22 October 2014 at 15:05:58 UTC, w0rp wrote:
> On Saturday, 18 October 2014 at 17:40:43 UTC, Walter Bright wrote:
>> On 10/18/2014 8:21 AM, Jacob Carlborg wrote:
>>> On 2014-10-18 07:09, Walter Bright wrote:

> never happen," which is like a car turning into King Kong and

It depends on the environment:

http://i.dailymail.co.uk/i/pix/2011/03/27/article-1370559-0B499D2E00000578-931_634x470.jpg

https://en.wikipedia.org/wiki/Code_smell
Do you read this?

Yes phobos.stdio very smell code. Disagree?
107 КБ of source code olny for call
few functions from stdio. Are you sure that
this code are full correctly?
"silly rabbit, y should be positive" - may
be becose his used class like this?

the funny thing is that this code can easily
be written machine based on a few rules and header.

Say that do you think about this code model
File("output"){
...
some file operation
...
}else{
...
optional if defined handle error
...
}
...

this not class instance, is macrodef.
And "output" is not a file, this
external resurce. His may binded to
commandline arg (-output), static file
 and gui(just set asign property in
design form editor). May be get from
network.
That is cool, about this i can say:
"Take it to bank". Gui on macros
like this may create very quick.

File declare as subject not class
(eg in json format) you anyway build it
from exists function.
example:
File = {
export: [ export list ]
blocks: {
main:{},
else: {}
},

}
Firshtein?
see https://en.wikipedia.org/wiki/Subject-oriented_programming
how this make on jscript https://github.com/jonjamz/amethyst

in the extreme case, if you want to change anything.
or as a way to shut problem quickly
add to debugging symbols generation algorithm info about file and line
- Walter?

On 9/27/14, 8:15 PM, Walter Bright wrote:
> This issue comes up over and over, in various guises. I feel like
> Yosemite Sam here:
>
>      https://www.youtube.com/watch?v=hBhlQgvHmQ0
>
> In that vein, Exceptions are for either being able to recover from
> input/environmental errors, or report them to the user of the application.
>
> When I say "They are NOT for debugging programs", I mean they are NOT
> for debugging programs.
>
> assert()s and contracts are for debugging programs.

Here's another +1 for exceptions.

I want to add a a slash command to Slack (https://slack.zendesk.com/hc/en-us/articles/201259356-Slash-Commands). So, for example, when I say:

/bot random phrase

This hits a web server that processes that request and returns a random phrase.

Now, imagine I have an assert in my application. When the web server hits the assertion it shuts down and the user doesn't get a response. What I'd like to do is to trap that assertion, tell the user that there's a problem, and send me an email telling me to debug it and fix it. That way the user can continue using the bot and I meanwhile I can fix the bug.

In the real world where you don't want unhappy users, asserts don't work.

Walter: how can you do that with an assertion triggering?

On Fri, Oct 24, 2014 at 03:29:43PM -0300, Ary Borenszweig via Digitalmars-d wrote:
> On 9/27/14, 8:15 PM, Walter Bright wrote:
> >This issue comes up over and over, in various guises. I feel like Yosemite Sam here:
> >
> >     https://www.youtube.com/watch?v=hBhlQgvHmQ0
> >
> >In that vein, Exceptions are for either being able to recover from input/environmental errors, or report them to the user of the application.
> >
> >When I say "They are NOT for debugging programs", I mean they are NOT for debugging programs.
> >
> >assert()s and contracts are for debugging programs.
> 
> Here's another +1 for exceptions.
> 
> I want to add a a slash command to Slack (https://slack.zendesk.com/hc/en-us/articles/201259356-Slash-Commands). So, for example, when I say:
> 
> /bot random phrase
> 
> This hits a web server that processes that request and returns a random phrase.
> 
> Now, imagine I have an assert in my application. When the web server hits the assertion it shuts down and the user doesn't get a response. What I'd like to do is to trap that assertion, tell the user that there's a problem, and send me an email telling me to debug it and fix it. That way the user can continue using the bot and I meanwhile I can fix the bug.
> 
> In the real world where you don't want unhappy users, asserts don't work.
> 
> Walter: how can you do that with an assertion triggering?

Sure they do.

Your application should be running in a separate process from the webserver itself. The webserver receives a request and forwards it to the application process. The application process processes the request and sends the response back to the webserver, which forwards it back on the client socket. Meanwhile, the webserver also monitors the application process; if it crashes before producing a response, it steps in and sends a HTTP 500 response to the client instead. It can also email you about the bug, possibly with the stack trace of the crashed application process, etc..  (And before you complain about inefficiency, there *are* ways of eliminating copying overhead when forwarding requests/responses between the client and the application.)

But if the webserver itself triggers an assertion, then it should NOT attempt to send anything back to the client, because the assertion may be indicating some kind of memory corruption or security exploit attempt. You don't know if you might be accidentally sending sensitive personal data (e.g. password for another user) back to the wrong client, because your data structures got scrambled and the wrong data is associated with the wrong client now.

Basically, if you want a component to recover from a serious problem like a failed assertion, the recovery code should be in a *separate* component. Otherwise, if the recovery code is within the failing component, you have no way to know if the recovery code itself has been compromised, and trusting that it will do the right thing is very dangerous (and is what often leads to nasty security exploits). The watcher must be separate from the watched, otherwise how can you trust the watcher?


T

-- 
Why ask rhetorical questions? -- JC

On 10/24/2014 11:29 AM, Ary Borenszweig wrote:
> On 9/27/14, 8:15 PM, Walter Bright wrote:
> Now, imagine I have an assert in my application. When the web server hits the
> assertion it shuts down and the user doesn't get a response. What I'd like to do
> is to trap that assertion, tell the user that there's a problem, and send me an
> email telling me to debug it and fix it. That way the user can continue using
> the bot and I meanwhile I can fix the bug.

Don't need an exception for that.

You can insert your own handler with core.assertHandler(myAssertHandler). Or you can catch(Error). But you don't want to try doing anything more than notification with that - the program is in an unknown state.

On Tuesday, 14 October 2014 at 15:57:05 UTC, eles wrote:
> On Saturday, 4 October 2014 at 05:26:52 UTC, eles wrote:
>> On Friday, 3 October 2014 at 20:31:42 UTC, Paolo Invernizzi wrote:
>>> On Friday, 3 October 2014 at 18:00:58 UTC, Piotrek wrote:
>>>> On Friday, 3 October 2014 at 15:43:59 UTC, Sean Kelly wrote:
>
>>
>> For the curious, the flight analysis here:
>>
>> http://www.popularmechanics.com/technology/aviation/crashes/what-really-happened-aboard-air-france-447-6611877
>>
>
> A just-printed new analysis of the same:
>
> http://www.vanityfair.com/business/2014/10/air-france-flight-447-crash

& the movie of it:

http://www.almdares.net/vz/youtube_browser.php?do=show&vidid=TsgyBqlFixo

On Friday, 24 October 2014 at 19:09:23 UTC, Walter Bright wrote:
>
> You can insert your own handler with core.assertHandler(myAssertHandler). Or you can catch(Error). But you don't want to try doing anything more than notification with that - the program is in an unknown state.

Also be aware that if you throw an Exception from the assertHandler you could be violating nothrow guarantees.

On 18/10/2014 18:40, Walter Bright wrote:
> As I've said before, tripping an assert by definition means the program
> has entered an unknown state. I don't believe it is possible for any
> language to make guarantees beyond that point.

The guarantees (if any), would not be made by the language, but by the programmer. The language cannot know if a program is totally broken and undefined when an assert fails, but a programmer can, for each particular assert, make some assumptions about which fault domains (like Sean put it) can be affected and which are not.


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 10/29/2014 5:37 AM, Bruno Medeiros wrote:
> On 18/10/2014 18:40, Walter Bright wrote:
>> As I've said before, tripping an assert by definition means the program
>> has entered an unknown state. I don't believe it is possible for any
>> language to make guarantees beyond that point.
>
> The guarantees (if any), would not be made by the language, but by the
> programmer. The language cannot know if a program is totally broken and
> undefined when an assert fails, but a programmer can, for each particular
> assert, make some assumptions about which fault domains (like Sean put it) can
> be affected and which are not.

Assumptions are not guarantees.

In any case, if the programmer knows than assert error is restricted to a particular domain, and is recoverable, and wants to recover from it, use enforce(), not assert().