On 9/28/2014 9:23 AM, Sean Kelly wrote:
> Also, I think the idea that a program is created and shipped to an end user is
> overly simplistic.  In the server/cloud programming world, when an error occurs,
> the client who submitted the request will get a response appropriate for them
> and the system will also generate log information intended for people working on
> the system.  So things like stack traces and assertion failure information is
> useful even for production software.  Same with any critical system, as I'm sure
> you're aware.  The systems are designed to handle failures in specific ways, but
> they also have to leave a breadcrumb trail so the underlying problem can be
> diagnosed and fixed.  Internal testing is never perfect, and achieving a high
> coverage percentage is nearly impossible if the system wasn't designed from the
> ground up to be testable in such a way (mock frameworks and such).

Then use assert(). That's just what it's for.

On 9/28/2014 2:28 AM, bearophile wrote:
>> And for exceptions I agree completely with your arguments and I think that
>> there is no need for stack.
> I think Walter is not suggesting to remove the stack trace for exceptions.

I suggest removal of stack trace for exceptions, but leaving them in for asserts.

Asserts are a deliberately designed debugging tool. Exceptions are not.

On 9/28/2014 8:10 AM, Ary Borenszweig wrote:
> For me, assert is useless.
>
> We are developing a language using LLVM as our backend. If you give LLVM
> something it doesn't like, you get something this:
>
> ~~~
> Assertion failed: (S1->getType() == S2->getType() && "Cannot create binary
> operator with two operands of differing type!"), function Create, file
> Instructions.cpp, line 1850.
>
> Abort trap: 6
> ~~~
>
> That is what the user gets when there is a bug in the compiler, at least when we
> are generating invalid LLVM code. And that's one of the good paths, if you
> compiled LLVM with assertions, because otherwise I guess it's undefined behaviour.
>
> What I'd like to do, as a compiler, is to catch those errors and tell the user:
> "You've found a bug in the app, could you please report it in this URL? Thank
> you.". We can't: the assert is there and we can't change it.

You can hook D's assert and do what you want with it.


> Now, this is when you interface with C++/C code. But inside our language code we
> always use exceptions so that programmers can choose what to do in case of an
> error. With assert you loose that possibility.

If you want to use Exceptions for debugging in your code, I won't try and stop you. But using them for debugging in official Phobos I strongly object to.


> Installing an exception handler is cost-free,

Take a look at the assembler dump from std.file.copy() that I posted in the other thread.


> so I don't see why there is a need
> for a less powerful construct like assert.

Exceptions are meant for RECOVERABLE errors. If you're using them instead of assert for logic bugs, you're looking at undefined behavior. Logic bugs are not recoverable.

On 9/28/14, 10:36 AM, Walter Bright wrote:
> On 9/28/2014 2:28 AM, bearophile wrote:
>>> And for exceptions I agree completely with your arguments and I think
>>> that
>>> there is no need for stack.
>> I think Walter is not suggesting to remove the stack trace for
>> exceptions.
>
> I suggest removal of stack trace for exceptions, but leaving them in for
> asserts.
>
> Asserts are a deliberately designed debugging tool. Exceptions are not.

I'm fine with that philosophy, with the note that it's customary nowadays to inflict things like the stack trace on the user. -- Andrei

Walter Bright:

> I suggest removal of stack trace for exceptions, but leaving them in for asserts.

I suggest to keep stack trace for both cases, and improve it with colors :-) Another possibility is to keep the stack trace for exceptions in nonrelease mode only.


> Asserts are a deliberately designed debugging tool. Exceptions are not.

Exceptions are often used to help debugging... We have even allowed exceptions inside D contracts (but I don't know why).

Bye,
bearophile

On 9/28/2014 11:25 AM, bearophile wrote:
> Exceptions are often used to help debugging...


https://www.youtube.com/watch?v=hBhlQgvHmQ0

On 2014-09-28 19:36, Walter Bright wrote:

> I suggest removal of stack trace for exceptions, but leaving them in for
> asserts.

If you don't like the stack track, just wrap the "main" function in a try-catch block, catch all exceptions and print the error message.

-- 
/Jacob Carlborg

On Sunday, 28 September 2014 at 17:33:38 UTC, Walter Bright wrote:
> On 9/28/2014 9:23 AM, Sean Kelly wrote:
>> Also, I think the idea that a program is created and shipped to an end user is overly simplistic.  In the server/cloud programming world, when an error occurs, the client who submitted the request will get a response appropriate for them and the system will also generate log information intended for people working on the system.  So things like stack traces and assertion failure information is useful even for production software.  Same with any critical system, as I'm sure you're aware.  The systems are designed to handle failures in specific ways, but they also have to leave a breadcrumb trail so the underlying problem can be diagnosed and fixed.  Internal testing is never perfect, and achieving a high coverage percentage is nearly impossible if the system wasn't designed from the ground up to be testable in such a way (mock frameworks and such).
>
> Then use assert(). That's just what it's for.

What if I don't want to be forced to abort the program in the event of such an error?

On Sunday, 28 September 2014 at 17:36:14 UTC, Walter Bright wrote:
> On 9/28/2014 2:28 AM, bearophile wrote:
>>> And for exceptions I agree completely with your arguments and I think that
>>> there is no need for stack.
>> I think Walter is not suggesting to remove the stack trace for exceptions.
>
> I suggest removal of stack trace for exceptions, but leaving them in for asserts.
>
> Asserts are a deliberately designed debugging tool. Exceptions are not.

Fair.  So we generate traces for Errors but not Exceptions.

On Sunday, 28 September 2014 at 17:40:49 UTC, Walter Bright wrote:
>
> You can hook D's assert and do what you want with it.

With the caveat that you must finish by either exiting the app or throwing an exception, since the compiler doesn't generate a stack frame that can be returned from.

> Exceptions are meant for RECOVERABLE errors. If you're using them instead of assert for logic bugs, you're looking at undefined behavior. Logic bugs are not recoverable.

In a multithreaded program, does this mean that the thread must be terminated or the entire process?  In a multi-user system, does this mean the transaction or the entire process?  The scope of a logic bug can be known to be quite limited.  Remember my earlier point about Erlang, where a "process" there is actually just a logical thread in the VM.