Program logic bugs vs input/environmental errors

[Ary Borenszweig via Digitalmars-d]

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.

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.

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.

Raising an exception is costly, but that should happen in exceptional 
cases. Installing an exception handler is cost-free, so I don't see why 
there is a need for a less powerful construct like assert.