On Thursday, 1 June 2017 at 17:03:52 UTC, Ali Çehreli wrote:
> On 06/01/2017 08:41 AM, Vasileios Anagnostopoulos wrote:
>
>> //If I do not know
>>
>> void haveToCommunicateWithAli() {
>> sendEmailToAli();
>> }
>>
>> //can blow-up after code has shipped
>> //and have no chance to recover
>>
>>
>> What shall I do in this case? Thank you in advance.
>>
>> Vasileios
>
> (Sorry if I go to too basic levels here.) I used to think that an unhandled exception was a program crash. It's not. It's a good thing that a program aborts due to an uhandled exception. What happened is that it could not achieve it's task. There was nothing else it could do, so it terminated. (For example, it did not continue with unhealthy radiation levels on the patient.)
>
> Although an abort may be the safest thing to do in many cases, it's not user-friendly. So, you catch the exception at the highest level that it matters or that you can do something about it. For example, you can catch the exception in main(), report a friendly error, and return 1.
>
> Or, you may be in a loop, preparing letters, you catch around that code and either report an error or perhaps grab more stamps and repeat the last operation.
>
> So the answer is, don't catch exceptions any lower than it really matters, which could be as high as the main() function.
>
> Ali

But still I believe that @nothrow should be mandatory if there is no possibility for a function to throw something. I understand that in the DLL/LIB level this is not possible. However, at least in the .di level it should be there.

And if you want my two cents, after reading a lot I came to the "personal" conclusion that Exception objects are wrong. For me it is enough to have something like

void A() {
 raise;
}

void B() {
 raise;
}

void C() {
 raise;
}


void D () nothrow { //the compiler inferred from body that D cannever throw

scope(failure) {
 writeln("The end of the world");
 exit(1);
}

try {
 A();
} else try {
  B();
} else {
 C();
}

}

On Friday, 2 June 2017 at 07:33:05 UTC, Vasileios Anagnostopoulos wrote:
> On Thursday, 1 June 2017 at 17:03:52 UTC, Ali Çehreli wrote:
>> [...]
>
> But still I believe that @nothrow should be mandatory if there is no possibility for a function to throw something. I understand that in the DLL/LIB level this is not possible. However, at least in the .di level it should be there.
>
> And if you want my two cents, after reading a lot I came to the "personal" conclusion that Exception objects are wrong. For me it is enough to have something like
>
> void A() {
>  raise;
> }
>
> void B() {
>  raise;
> }
>
> void C() {
>  raise;
> }
>
>
> void D () nothrow { //the compiler inferred from body that D cannever throw
>
> scope(failure) {
>  writeln("The end of the world");
>  exit(1);
> }
>
> try {
>  A();
> } else try {
>   B();
> } else {
>  C();
> }
>
> }

Or simply

void A() {
 raise;
}

void B() nothrow {
}


void D () nothrow { //the compiler inferred from body that D cannever throw

try {
 A();
} else {
  B();
}

}

On Wednesday, 31 May 2017 at 08:18:07 UTC, Vasileios Anagnostopoulos wrote:
> Hi,
>
> after reading various articles bout the "supposed" drawbacks of checked exceptions I started to have questions on @nothrow. Why there exists and not a @throws annotation enforced by the compiler? I understand that people are divided on checked exceptions and each side has some valid points. But explicitly marking a function as throwing "something" is another subject. Why have the dlang community reached to the decision to use @nothrow and not a @throws?

Adding @throws to a function requires changing all the functions downstream. Adding @nothrow doesn't.

On Wednesday, 31 May 2017 at 09:31:48 UTC, Jonathan M Davis wrote:
> On Wednesday, May 31, 2017 08:18:07 Vasileios Anagnostopoulos via Digitalmars-d-learn wrote:
>> [...]
>
> Well, if you're not doing checked exceptions, the interesting question is really what _doesn't_ throw rather than what throws, because if the compiler knows that a function doesn't throw, it can optimize out the exception handling mechanisms that are normally required.

I don't think this is possible in current D? @nothrow functions can still throw Error.

On 06/02/2017 12:35 AM, Vasileios Anagnostopoulos wrote:
> On Friday, 2 June 2017 at 07:33:05 UTC, Vasileios Anagnostopoulos wrote:

>> But still I believe that @nothrow should be mandatory if there is no
>> possibility for a function to throw something. I understand that in
>> the DLL/LIB level this is not possible. However, at least in the .di
>> level it should be there.
>>
>> And if you want my two cents, after reading a lot I came to the
>> "personal" conclusion that Exception objects are wrong. For me it is
>> enough to have something like

> Or simply
>
> void A() {
>  raise;
> }
>
> void B() nothrow {
> }
>
>
> void D () nothrow { //the compiler inferred from body that D cannever throw
>
> try {
>  A();
> } else {
>   B();
> }
>
> }

If I understand you correctly, you want the compiler to force the programmer to be explicit about @nothrow. That's an interesting idea... I don't have strong opinions on the matter.

To add to this discussion, there is the "Checked vs unchecked exceptions" thread currently active on the general newsgroup:

  http://forum.dlang.org/post/hxhjcchsulqejwxywfbn@forum.dlang.org

Ali