What is the point of nothrow if it can only detect when Exception is thrown and not when Error is thrown?

It seems like the attribute is useless because you can't really use it as protection to write bugless, safe code since the nasty bugs will pass by just fine.

I'm aware that it's a feature that nothrow can throw Error, but it makes the attribute completely useless because you basically have no safety to guard against writing code that throws Error.

To an extend @safe works, but there are tons of stuff that throws Error which you can only detect and guard against manually.

So what is the point of nothrow when it can only detect exceptions you'd catch anyway.

To me it would be so much more useful if you could detect code that could possibly throw Error.

On Sunday, June 10, 2018 23:59:17 Bauss via Digitalmars-d-learn wrote:
> What is the point of nothrow if it can only detect when Exception is thrown and not when Error is thrown?
>
> It seems like the attribute is useless because you can't really use it as protection to write bugless, safe code since the nasty bugs will pass by just fine.
>
> I'm aware that it's a feature that nothrow can throw Error, but it makes the attribute completely useless because you basically have no safety to guard against writing code that throws Error.
>
> To an extend @safe works, but there are tons of stuff that throws Error which you can only detect and guard against manually.
>
> So what is the point of nothrow when it can only detect exceptions you'd catch anyway.
>
> To me it would be so much more useful if you could detect code that could possibly throw Error.

Why do you care about detecting code that can throw an Error? Errors are supposed to kill the program, not get caught. As such, why does it matter if it can throw an Error?

Now, personally, I'm increasingly of the opinion that the fact that we have Errors is kind of dumb given that if it's going to kill the program, and it's not safe to do clean-up at that point, because the program is in an invalid state, then why not just print the message and stack trace right there and then kill the program instead of throwing anything? But unforntunately, that's not what happens, which does put things in the weird state where code can catch an Error even though it shouldn't be doing that.

As for the benefits of nothrow, as I understand it, they're twofold:

1. You know that you don't have to worry about any Exceptions being thrown from that code. You don't have to worry about doing any exception handling or having to ensure that anything gets cleaned up because of an Exception being thrown.

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 that it normally does when a function is called. It can assume that nothing ever gets thrown. If an Error does get thrown, then none of the proper clean-up will get done (e.g. constructors or scope statements), but because an Error being thrown means that the program is in an invalid state, it's not actually safe to be doing clean-up anyway. So, the fact that a function is nothrow gives you a performance benefit, because none of that extra Exception handling stuff gets inserted. How large a benefit that is in practice, I don't know, but it is a gain that can't be had with a function that isn't nothrow.

- Jonathan M Davis

On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote:
> On Sunday, June 10, 2018 23:59:17 Bauss via Digitalmars-d-learn wrote:
>> What is the point of nothrow if it can only detect when Exception is thrown and not when Error is thrown?
>>
>> It seems like the attribute is useless because you can't really use it as protection to write bugless, safe code since the nasty bugs will pass by just fine.
>>
>> I'm aware that it's a feature that nothrow can throw Error, but it makes the attribute completely useless because you basically have no safety to guard against writing code that throws Error.
>>
>> To an extend @safe works, but there are tons of stuff that throws Error which you can only detect and guard against manually.
>>
>> So what is the point of nothrow when it can only detect exceptions you'd catch anyway.
>>
>> To me it would be so much more useful if you could detect code that could possibly throw Error.
>
> Why do you care about detecting code that can throw an Error? Errors are supposed to kill the program, not get caught. As such, why does it matter if it can throw an Error?
>
> Now, personally, I'm increasingly of the opinion that the fact that we have Errors is kind of dumb given that if it's going to kill the program, and it's not safe to do clean-up at that point, because the program is in an invalid state, then why not just print the message and stack trace right there and then kill the program instead of throwing anything? But unforntunately, that's not what happens, which does put things in the weird state where code can catch an Error even though it shouldn't be doing that.
>
> As for the benefits of nothrow, as I understand it, they're twofold:
>
> 1. You know that you don't have to worry about any Exceptions being thrown from that code. You don't have to worry about doing any exception handling or having to ensure that anything gets cleaned up because of an Exception being thrown.
>
> 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 that it normally does when a function is called. It can assume that nothing ever gets thrown. If an Error does get thrown, then none of the proper clean-up will get done (e.g. constructors or scope statements), but because an Error being thrown means that the program is in an invalid state, it's not actually safe to be doing clean-up anyway. So, the fact that a function is nothrow gives you a performance benefit, because none of that extra Exception handling stuff gets inserted. How large a benefit that is in practice, I don't know, but it is a gain that can't be had with a function that isn't nothrow.
>
> - Jonathan M Davis

Well at least from my point of view I would care about code that can throw Error, because if say nothrow could detect that then you could prevent writing that code that throws jt at all and thus you'd be writing less error prone code.

Maybe not necessarily nothrow, but something else that could ensure that your code is "100% safe" to run without any errors happening from ex. Accessing out of bounds, accessing invalid memory, attempting to access the member of an uninitialized class etc. Like you'd have to handle each such cases. Writing code in D today you have to think about each statement you write and whether it could possibly throw Error because you have little to no tools that helps you preventing writing such code.

I'm very well aware that Error is not supposed to be caught and that the program is in an invalid state, but ehat I'm trying to get at is that if nothrow or at least a feature similar existed that could detect code that may throw Error, then you could prevent writing code that throws it in the first place.

It would be a great tool to writing bugless code.

On Monday, June 11, 2018 04:11:38 Bauss via Digitalmars-d-learn wrote:
> I'm very well aware that Error is not supposed to be caught and that the program is in an invalid state, but ehat I'm trying to get at is that if nothrow or at least a feature similar existed that could detect code that may throw Error, then you could prevent writing code that throws it in the first place.
>
> It would be a great tool to writing bugless code.

Well, the problem with that is that if you do anything involving assertions, dynamic arrays, or GC memory allocations, you can get an Error. The same goes for some stuff like final switch statements. Some of those Errors don't happen with -release (e.g. the check on final switch and asserion failures), but enough operations have to be checked at runtime that I expect that even if you ignored the ones that don't happen with -release, relatively little code could be guaranteed to not throw Errors. And most Errors are thrown because of Error conditions that can't reasonably be caught at compile time. So, while knowing that none of those Errors can happen in a particular piece of code might be nice, all it really means is that you're not doing any operations in that code which can be checked for error conditions at runtime but which can't be checked at compile time. On the whole, what Errors are really doing is catching the bugs that you didn't manage to catch yourself and that the compiler can't catch for you, but the runtime can. So, arguably, all you'd really be doing if you guaranteed that a piece of code didn't throw any Errors is guarantee that the code didn't do any operations where the runtime can catch bugs for you. As such, while you obviously don't want to end up having any Errors thrown in your program, I seriously question that trying to write code that is statically guaranteed to not throw any Errors is very useful or desirable - especially since it's not like such code is guaranteed to be bug-free. It just wouldn't have any of the bugs that the runtime can catch for you.

- Jonathan M Davis

On Monday, 11 June 2018 at 04:11:38 UTC, Bauss wrote:
> On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote:
>> On Sunday, June 10, 2018 23:59:17 Bauss via Digitalmars-d-learn wrote:
>>> What is the point of nothrow if it can only detect when Exception is thrown and not when Error is thrown?
>>>
>>> It seems like the attribute is useless because you can't really use it as protection to write bugless, safe code since the nasty bugs will pass by just fine.
>>>
>>> I'm aware that it's a feature that nothrow can throw Error, but it makes the attribute completely useless because you basically have no safety to guard against writing code that throws Error.
>>>
>>> To an extend @safe works, but there are tons of stuff that throws Error which you can only detect and guard against manually.
>>>
>>> So what is the point of nothrow when it can only detect exceptions you'd catch anyway.
>>>
>>> To me it would be so much more useful if you could detect code that could possibly throw Error.
>>
>> Why do you care about detecting code that can throw an Error? Errors are supposed to kill the program, not get caught. As such, why does it matter if it can throw an Error?
>>
>> Now, personally, I'm increasingly of the opinion that the fact that we have Errors is kind of dumb given that if it's going to kill the program, and it's not safe to do clean-up at that point, because the program is in an invalid state, then why not just print the message and stack trace right there and then kill the program instead of throwing anything? But unforntunately, that's not what happens, which does put things in the weird state where code can catch an Error even though it shouldn't be doing that.
>>
>> As for the benefits of nothrow, as I understand it, they're twofold:
>>
>> 1. You know that you don't have to worry about any Exceptions being thrown from that code. You don't have to worry about doing any exception handling or having to ensure that anything gets cleaned up because of an Exception being thrown.
>>
>> 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 that it normally does when a function is called. It can assume that nothing ever gets thrown. If an Error does get thrown, then none of the proper clean-up will get done (e.g. constructors or scope statements), but because an Error being thrown means that the program is in an invalid state, it's not actually safe to be doing clean-up anyway. So, the fact that a function is nothrow gives you a performance benefit, because none of that extra Exception handling stuff gets inserted. How large a benefit that is in practice, I don't know, but it is a gain that can't be had with a function that isn't nothrow.
>>
>> - Jonathan M Davis
>
> Well at least from my point of view I would care about code that can throw Error, because if say nothrow could detect that then you could prevent writing that code that throws jt at all and thus you'd be writing less error prone code.
>
> Maybe not necessarily nothrow, but something else that could ensure that your code is "100% safe" to run without any errors happening from ex. Accessing out of bounds, accessing invalid memory, attempting to access the member of an uninitialized class etc. Like you'd have to handle each such cases. Writing code in D today you have to think about each statement you write and whether it could possibly throw Error because you have little to no tools that helps you preventing writing such code.
>
> I'm very well aware that Error is not supposed to be caught and that the program is in an invalid state, but ehat I'm trying to get at is that if nothrow or at least a feature similar existed that could detect code that may throw Error, then you could prevent writing code that throws it in the first place.
>
> It would be a great tool to writing bugless code.

There's nothing unsafe about Error getting thrown in your code. Error makes your program more safe, because it terminates the program immediately instead of letting it do stuff like corrupt memory or crash the system.

Error getting thrown denotes a logic error in your program. Some base assumption you've made is not actually true, and thus the program is in an invalid state and must exit immediately. The reason why nothrow cannot help you here is because these are logic errors that are only detectable at runtime. If it was possible to detect these types of errors at compile time, then there would be no need for Error.

On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote:
> On Sunday, June 10, 2018 23:59:17 Bauss via Digitalmars-d-learn wrote:
>> What is the point of nothrow if it can only detect when Exception is thrown and not when Error is thrown?
>>
>> It seems like the attribute is useless because you can't really use it as protection to write bugless, safe code since the nasty bugs will pass by just fine.
>>
>> I'm aware that it's a feature that nothrow can throw Error, but it makes the attribute completely useless because you basically have no safety to guard against writing code that throws Error.
>>
>> To an extend @safe works, but there are tons of stuff that throws Error which you can only detect and guard against manually.
>>
>> So what is the point of nothrow when it can only detect exceptions you'd catch anyway.
>>
>> To me it would be so much more useful if you could detect code that could possibly throw Error.
>
> Why do you care about detecting code that can throw an Error? Errors are supposed to kill the program, not get caught. As such, why does it matter if it can throw an Error?
>
> Now, personally, I'm increasingly of the opinion that the fact that we have Errors is kind of dumb given that if it's going to kill the program, and it's not safe to do clean-up at that point, because the program is in an invalid state, then why not just print the message and stack trace right there and then kill the program instead of throwing anything? But unforntunately, that's not what happens, which does put things in the weird state where code can catch an Error even though it shouldn't be doing that.

It certainly threw (hardehar) me when a failed assert was terminating my program without telling me why. I don't know if it's just because it was happening in an OS callback function, but it was definitely a WTF.

So the only solution I could figure is to catch throwable in the callback function, dump the message, and then PostQuitMessage(0). It just seems retarded that Throwables can still happen in a nothrow function.

On Monday, June 11, 2018 20:45:52 Dave Jones via Digitalmars-d-learn wrote:
> On Monday, 11 June 2018 at 00:47:27 UTC, Jonathan M Davis wrote:
> > On Sunday, June 10, 2018 23:59:17 Bauss via Digitalmars-d-learn
> >
> > wrote:
> >> What is the point of nothrow if it can only detect when Exception is thrown and not when Error is thrown?
> >>
> >> It seems like the attribute is useless because you can't really use it as protection to write bugless, safe code since the nasty bugs will pass by just fine.
> >>
> >> I'm aware that it's a feature that nothrow can throw Error, but it makes the attribute completely useless because you basically have no safety to guard against writing code that throws Error.
> >>
> >> To an extend @safe works, but there are tons of stuff that throws Error which you can only detect and guard against manually.
> >>
> >> So what is the point of nothrow when it can only detect exceptions you'd catch anyway.
> >>
> >> To me it would be so much more useful if you could detect code that could possibly throw Error.
> >
> > Why do you care about detecting code that can throw an Error? Errors are supposed to kill the program, not get caught. As such, why does it matter if it can throw an Error?
> >
> > Now, personally, I'm increasingly of the opinion that the fact that we have Errors is kind of dumb given that if it's going to kill the program, and it's not safe to do clean-up at that point, because the program is in an invalid state, then why not just print the message and stack trace right there and then kill the program instead of throwing anything? But unforntunately, that's not what happens, which does put things in the weird state where code can catch an Error even though it shouldn't be doing that.
>
> It certainly threw (hardehar) me when a failed assert was terminating my program without telling me why. I don't know if it's just because it was happening in an OS callback function, but it was definitely a WTF.

Because Errors are handled as Throwables, they have to be caught to print out what went wrong. So, if you do something like give an extern(C) function to a C function via a function pointer, and it throws an Error, then you will probably have to catch it, print it, and then do whatever is appropriate at that point to shut down the program, whereas if it just killed the program at the point that the Error was thrown, then that wouldn't be a problem. So, that's a definite downside to the fact that Errors are thrown instead of just printing and killing the program. Another potentially serious downside is that if the program dies at the point of failure, then you can often get a coredump of the program state to debug it, whereas if an Error is thrown, then that doesn't happen.

I think that part of what caused this situation is the fact that Walter has primarily worked on programs where you can restart them to get the same results (like a compiler). So, he's not used to having to debug a program failure where the program has been running for who knows how long, and you don't even know what the program input was. So, he has a tendency to expect you to be able to rerun the program to get the same results in order to debug it, whereas folks writing OS or server software are more likely to expect to have to capture the program state at the point of failure so that they have some hope of debugging the problem when they have no clue of how to reproduce it.

> So the only solution I could figure is to catch throwable in the callback function, dump the message, and then PostQuitMessage(0). It just seems retarded that Throwables can still happen in a nothrow function.

Well, it stems from the fact that Exceptions and Throwables are essentially different things but use essentially the same error-reporting mechanism. In a way, it make sense (especially in the case where you're dealing with a single thread that D controls), but I'm inclined to think that it was ultimately a mistake.

- Jonathan M Davis

On Sunday, 10 June 2018 at 23:59:17 UTC, Bauss wrote:
> To me it would be so much more useful if you could detect code that could possibly throw Error.

Such things are usually done by formal verification systems like F*, and I suppose Ada 2012 has it to some extent too. Though I suspect it's not easy to use, less easy than rust.

On 6/11/18 5:23 PM, Jonathan M Davis wrote:
> On Monday, June 11, 2018 20:45:52 Dave Jones via Digitalmars-d-learn wrote:
>> So the only solution I could figure is to catch throwable in the
>> callback function, dump the message, and then PostQuitMessage(0).
>> It just seems retarded that Throwables can still happen in a
>> nothrow function.
> 
> Well, it stems from the fact that Exceptions and Throwables are essentially
> different things but use essentially the same error-reporting mechanism. In
> a way, it make sense (especially in the case where you're dealing with a
> single thread that D controls), but I'm inclined to think that it was
> ultimately a mistake.

I agree that the fact you can catch throwables is a mistake, but at the same time, there are Errors thrown for things that shouldn't be Errors (like RangeError). This forces you to deal with them in places where it shouldn't be necessary.

I predict at some point when Errors actually don't do proper cleanup, it is going to be a really difficult time for D.

-Steve

On 6/10/18 7:59 PM, Bauss wrote:
> What is the point of nothrow if it can only detect when Exception is thrown and not when Error is thrown?
> 
> It seems like the attribute is useless because you can't really use it as protection to write bugless, safe code since the nasty bugs will pass by just fine.

Array invalid index throws Error, and asserts throw Error. I'm not sure how much you could accomplish without such features. In fact, I'd consider these ESSENTIAL to writing safe code.

Bug-free code is a myth :)

-Steve