On Thursday, 14 June 2018 at 19:06:07 UTC, Jonathan M Davis wrote:
> As I said, personally, I think that the program shut just print and terminate rather than throwing an Error. Walter seems to

It makes perfectly sense for it to throw an error and not just print and terminate.

This is especially true for server applications and especially server applications running in the cloud where you do not necessarily have access to a console, but you most likely will have access to a database.

So in case of a thrown Error, you can catch it and log it to a database.

If it was just printing it would be a lot hard to do such a task, especially when you take permission etc. into account.

D would _never_ be fit for large scalable applications if it wasn't possible to retrieve the errors on any system and platform, no matter your limitations.

On Wednesday, 13 June 2018 at 17:08:26 UTC, wjoe wrote:
> My question was more like what's the benefit of having thrown Errors corrupt your program state  rendering it useless for debugging ?

D allows various levels of performance and safety. Though I'd say Errors not working in debug mode is not intended, the optimization should work in release mode which implies debugged code and assumes there are no Errors thrown and you get extra optimization for nothrow functions. Errors are a cheap way to print diagnostic, because you need to do it for unhandled exceptions anyway and it's cross-platform too unlike debugger. Also leaf functions don't know anything about environment and can't do meaningful I/O, e.g. realistically you have standard output only in console applications and not in other applications.

On Thursday, 14 June 2018 at 22:27:42 UTC, bauss wrote:
> On Thursday, 14 June 2018 at 19:06:07 UTC, Jonathan M Davis wrote:
> So in case of a thrown Error, you can catch it and log it to a database.
>

No, you can't. Once the Error was thrown the program is in invalid state and you can't assume the logging to database will succeed.

If I understood Johnathan's explanations correctly, you can't even be sure that the Error can be caught, since its only purpose is to jump to the print and abort function.

This is exactly what I was asking about. Logging, cleanup, executing an emergency stop..not possible.

On Friday, 15 June 2018 at 17:25:18 UTC, wjoe wrote:
> On Thursday, 14 June 2018 at 22:27:42 UTC, bauss wrote:
>> On Thursday, 14 June 2018 at 19:06:07 UTC, Jonathan M Davis wrote:
>> So in case of a thrown Error, you can catch it and log it to a database.
>>
>
> No, you can't. Once the Error was thrown the program is in invalid state and you can't assume the logging to database will succeed.

Sure you can assume it will succeed, BUT in 9/10 cases it will and in those cases it's worth it.

I do that and it has proven to work every single time for me.

You can't assume it will succeed writing to a log file either.

In either cases you just have to try and hope for the best.

On Friday, 15 June 2018 at 17:27:13 UTC, bauss wrote:
> On Friday, 15 June 2018 at 17:25:18 UTC, wjoe wrote:
>> On Thursday, 14 June 2018 at 22:27:42 UTC, bauss wrote:
>>> On Thursday, 14 June 2018 at 19:06:07 UTC, Jonathan M Davis wrote:
>>> So in case of a thrown Error, you can catch it and log it to a database.
>>>
>>
>> No, you can't. Once the Error was thrown the program is in invalid state and you can't assume the logging to database will succeed.
>
> Sure you can assume it will succeed, BUT in 9/10 cases it will and in those cases it's worth it.
>
> I do that and it has proven to work every single time for me.
>
> You can't assume it will succeed writing to a log file either.
>
> In either cases you just have to try and hope for the best.

There is a reason that I have not gotten rid of this: http://diamondmvc.org/docs/logging/#database-logging

It just _works_ most of the time and really helpful when you do not have access to the server and/or the standard output/console.

On Friday, 15 June 2018 at 08:13:44 UTC, Kagamin wrote:
> On Wednesday, 13 June 2018 at 17:08:26 UTC, wjoe wrote:
>> My question was more like what's the benefit of having thrown Errors corrupt your program state  rendering it useless for debugging ?
>
> D allows various levels of performance and safety. Though I'd say Errors not working in debug mode is not intended, the

Intention matters not. By definition all program state is invalid at the point an Error was thrown. From there on it is impossible to rely on any output, too, because it could be either correct, corrupted, or completely invalid.
Your objects might have been destructed, or maybe not or maybe just partially.
The only thing safe to assume is that what you've got is useless.


> optimization should work in release mode which implies debugged code and assumes there are no Errors thrown and you get extra optimization for nothrow functions. Errors are a cheap way to print diagnostic, because you need to do it for unhandled exceptions anyway and it's cross-platform too unlike debugger.

A core dump is created by the OS. In a format that a native debugger understands.

> Also leaf functions don't know anything about environment and can't do meaningful I/O, e.g. realistically you have standard output only in console applications and not in other applications.

Exactly. You may not have a console at all, like eg. in Windows for the most part, or even Linux if you launch the program from a toolbar button, and what about headless configurations. What good is printing to stderr in these cases ?

The only sensible thing to do in case of an unrecoverable Error is to transfer control back to the OS right away and let it handle the rest.
A mechanism of Errors thrown like Exceptions is too tempting to mess around with.

Scott Meyers wrote in one of his books, I forget which, that your design should be easy to use correctly and hard or impossible to use incorrectly. This is not true for D Errors.

On Friday, 15 June 2018 at 17:27:13 UTC, bauss wrote:
> On Friday, 15 June 2018 at 17:25:18 UTC, wjoe wrote:
>> On Thursday, 14 June 2018 at 22:27:42 UTC, bauss wrote:
>>> On Thursday, 14 June 2018 at 19:06:07 UTC, Jonathan M Davis wrote:
>>> So in case of a thrown Error, you can catch it and log it to a database.
>>>
>>
>> No, you can't. Once the Error was thrown the program is in invalid state and you can't assume the logging to database will succeed.
>
> Sure you can assume it will succeed, BUT in 9/10 cases it will and in those cases it's worth it.
>
> I do that and it has proven to work every single time for me.
>
> You can't assume it will succeed writing to a log file either.
>
> In either cases you just have to try and hope for the best.

Casting away const 'works' too, but is undefined behavior and is not guaranteed to work in  future implementations.
Likewise, this may work in the current implementation but there's no guarantee that's to stay.
At the time of throw Error the program must be considered dead.
It sucks, but even if something was logged to the DB you can't rely on this information to be correct.
Please read Jonathan's posts further up, he explained the internals and Walter Bright's reasoning in detail.

On 6/15/18 1:27 PM, bauss wrote:
> On Friday, 15 June 2018 at 17:25:18 UTC, wjoe wrote:
>> On Thursday, 14 June 2018 at 22:27:42 UTC, bauss wrote:
>>> On Thursday, 14 June 2018 at 19:06:07 UTC, Jonathan M Davis wrote:
>>> So in case of a thrown Error, you can catch it and log it to a database.
>>>
>>
>> No, you can't. Once the Error was thrown the program is in invalid state and you can't assume the logging to database will succeed.
> 
> Sure you can assume it will succeed, BUT in 9/10 cases it will and in those cases it's worth it.
> 
> I do that and it has proven to work every single time for me.
> 
> You can't assume it will succeed writing to a log file either.
> 
> In either cases you just have to try and hope for the best.

You can't assume anything when catching an Error. I would not recommend writing to a database in that case.

I brought up a similar situation last year: https://forum.dlang.org/post/ogmf1l$2mp8$1@digitalmars.com

My solution was simply to replace the array with a wrapper which throws an exception instead. I can't figure out any better way to do it, and really, we can't change the way out-of-bounds errors work.

-Steve

On Friday, 15 June 2018 at 17:29:39 UTC, bauss wrote:
> [snip]
>
> There is a reason that I have not gotten rid of this: http://diamondmvc.org/docs/logging/#database-logging
>
> It just _works_ most of the time and really helpful when you do not have access to the server and/or the standard output/console.

I wouldn’t doubt that a lot of behavior depends on the current approach of Errors inheriting from Throwable. I’m sure you find value in it the way it is and I bet it would be a pain to change it.

Instead, what if they introduced an UnthrowableError that does not inherit from Throwable and just kills the program without unwinding the stack or whatever else people find objectionable currently? The current Error could be re-named Throwable Error and then a new Error could be introduced that has version statements such that whether to call ThrowableError or UnthrowableError depends on switches when you compile. This way you can still have the behavior that you like, though maybe the default would change at some point in the future.

The only breaking changes I can figure would be if people are assuming that Error always inherits Throwable, when it wouldn’t if using the UnthrowableError switch.

On Thursday, 14 June 2018 at 19:06:07 UTC, Jonathan M Davis wrote:
> On Thursday, June 14, 2018 18:11:20 wjoe via Digitalmars-d-learn wrote:
>> On Wednesday, 13 June 2018 at 20:08:06 UTC, Jonathan M Davis wrote:
>> > On Wednesday, June 13, 2018 10:56:41 wjoe via
>> > The idea is that because your program is in an invalid state,
>> > attempting a graceful shutdown is unsafe. But regardless of
>> > whether you agree with that, the fact that nothrow doesn't do
>> > clean-up pretty much ensures that it isn't safe in the general
>> > case, and nothrow can't do clean-up without negating one of the
>> > main reasons that it exists in the first place - which is to
>>
>> that fact also means that a program which threw an Error cannot be debugged anymore; because of invalid state you can neither know, nor assume, that what you see in your debugger or core dump is actually the state which led to the throw.
>
> As I said, personally, I think that the program shut just print and terminate rather than throwing an Error. Walter seems to have designed things from the premise that you could rerun the program to reproduce the problem (which in is usually true with the programs he works on). And in that case, simply getting the error message and stacktrace would be plenty. The problem is when you can't simply rerun the program to reproduce the problem and is why I'm of the opinion that printing and terminating would be better than throwing an Error.
>
>> > improve performance by not emitting exception-handling code.
>>
>> if performance matters so much I would use betterC.
>>
>> 'Improving' performance without profiling and such a trade-off is a bad idea. If it were opt in - yes, I know I will get undebuggable code on error thrown but I want or need the performance gain, fair enough. But instead you are a victim of that implementation whether you like it or not and you might not even be aware about it.
>
> betterC really has nothing to do with performance. It just has to do with avoiding druntime so that you can have C code just link in and use the D code as if it were C (though using it would avoid the issue of Errors, since the runtime wouldn't be there to handle them). And again, Errors are intended for fatal cases, so most of the concerns about doing clean-up are irrelevant. Attempting to recover from an Error is considered to be like attempting to recover from a segfault, which is a terrible, terrible idea. And there are plenty of folks who want to be able to have their code be more performant when it's not using exceptions. So, as long as folks aren't trying to catch Errors, the fact that nothrow doesn't emit the exception handling code really isn't a problem.
>

What you said earlier:
On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote:
>
> [...]
>
> 2. If the compiler knows that a function can't throw an Exception, then it doesn't have to insert any of the Exception handling mechanism stuff [...] So, the fact that a function is nothrow gives you a performance benefit, [...]
>
> - Jonathan M Davis

made me believe that performance is one of the major reasons to use it. No?

From the betterC page https://dlang.org/spec/betterc.html section 40.2:
---
Not Available

D features not available with BetterC:

    Garbage Collection
    TypeInfo and ModuleInfo
    Classes
    Built-in threading (e.g. core.thread)
    Dynamic arrays (though slices of static arrays work) and associative arrays
    Exceptions
    switch with strings
    final switch
    synchronized and core.sync
    Static module constructors or destructors
    Struct destructors
    unittest (testing can be done without the -betterC flag)
---
Apart from a few convenience features lost this list reads like a shopping list for performance gain over full fledged D, in the spirit of nothrow omitting exception handling mechanism, to me. You gain from no garbage collection overhead, no vtable overhead, no RTTI overhead, no exception overhead, etc, etc, ...

Back in the late 90ies I used to write the lion's share of code in Pascal and implement mission critical algorithms in asm. Worked back then why wouldn't it work today, except that I wouldn't use asm anymore but something like C or betterC.

Thus, people who need this kind of performance boost can benefit 2 fold from using betterC.
1. They get to keep most of D's awesomeness, including compile time features, scope statements, RAII, lack of a pre processor, memory safety protections and complete meta programming, are just _some_ of the highlights. And on the other hand
2. they gain by getting rid of a lot the 'performance hogs' like GC, exceptions and more, right?
And, with no exceptions altogether they do not need to worry about it at all.

I'm sold!


>> And out of curiosity again, where would I find this place where the printing and terminating occurs ?
>
> I'd have to go digging in druntime. I don't know. I've probably seen it before, but it's not code that I've dealt with often enough to remember exactly where it is off the top of my head.

druntime. that's a starting point. Thanks.


>> Aborting with an error code would be sufficient. No need to print
>> anything.
>> A backtrace can be obtained in the debugger.
>
> Given that a coredump isn't always generated (and in the case of Windows, I don't know if they even have an equivalent), printing out the same information that gets printed out now would often be desirable. It's just that if it kills the program right there rather than doing any unwinding of the stack, then the coredump is for the state of the program at the point of failure like it arguably should be.

true enough, but I'm sure that the average user wouldn't know what to do with a stack trace in a console and would have closed it long before contacting tech support.
We're speaking of rare errors so chances are high that they happen in shipped code.
Also, as I noted above in a previous post, there might not even be a console(like device) attached to be able to print the error and stack trace.

I also believe that Exceptions and Errors should not carry a message string because 1. the Exception/Error name carries the reason in itself, 2. you can't work well with strings and 3. l18n.

It would be better to write that data out into a file and inform the user there was a problem and they should please submit file a and file b to the developer, if possible with a description of what they were doing. That is for Exceptions.
In case of an Error just inform them that the program crashed and cannot be recovered and they should just restart it and apologies for the inconvenience.
They needn't bother about sending anything because that info is just a dump of invalid program state.

Windows creates core dumps, except they use their own terminology. I believe to recall they come in 2 flavors, full- and mini-dumps but to my knowledge, which is older than 12 years, those were uploaded to MS and you needed to have a Visual Studio enterprise level subscription or be a registered developer to be able to retrieve them from MS, that is the ones that were created on machines you don't have access to. I don't know what the current way to do it is.

I think it's possible to generate a core dump via gencore, and Windows has MiniDumpWrite or something to that end.