October 10, 2020
On Saturday, 10 October 2020 at 19:55:44 UTC, Ali Çehreli wrote:
> On 10/10/20 12:51 PM, DMon wrote:
>
Thank you for your and Imperatorns time.

Even if it did go in circles and get stuck in the mud.
October 10, 2020
On Saturday, 10 October 2020 at 20:32:22 UTC, DMon wrote:
> On Saturday, 10 October 2020 at 19:55:44 UTC, Ali Çehreli wrote:
>> On 10/10/20 12:51 PM, DMon wrote:
>>
> Thank you for your and Imperatorns time.
>
> Even if it did go in circles and get stuck in the mud.

No problem. We're doing it out of free will :)
October 12, 2020
On Saturday, 10 October 2020 at 19:51:10 UTC, DMon wrote:

> This is where I'm at:
>
> import std.stdio;
> import std.conv;
>
> // StdioException
> // ConvException
> // StringException
> // ErrnoException
> // FormatException
> // UnicodeException
> // UTFException
> // FileMissingException
> // DataCorruptionException
> // FE_INEXACT
> // FE_UNDERFLOW
> // FE_OVERFLOW
> //

- You should not care about exceptions someone else defined in his library (maybe except for printing out their message in main(), for which you don't need to know the exact type).
- You should not reuse exceptions defined by someone else. Define your own.
- Throw exceptions only if you have a plan what to do with them if you catch them.
- If you have no plan, better throw error, just to get an idea where and why the program crashed (and don't try to catch them)

Therefore a list of possible exceptions doesn't make any sense.
October 12, 2020
On Monday, 12 October 2020 at 09:11:35 UTC, Dominikus Dittes Scherkl wrote:

>
> - ...not care about exceptions someone else defined...except for printing out their message in main()...
> - ...not reuse exceptions defined by someone else. Define your own.
> - ...only if you have a plan...
> - ...no plan, better throw error...where and why the program crashed...
>
> Therefore a list of possible exceptions doesn't make any sense.

Thanks, Dominikus, those are great ideas.


October 12, 2020
On 10/12/20 2:11 AM, Dominikus Dittes Scherkl wrote:

> - Throw exceptions only if you have a plan what to do with them if you
> catch them.

My thinking is different: Throw exceptions if you can't accomplish a task. My code is filled with enforce() and assert() checks, which do throw exceptions.

> - If you have no plan, better throw error, just to get an idea where and
> why the program crashed (and don't try to catch them)

In most cases, catching Exception (not Error) to print exc.msg is fine and is the correct thing to do. (Errors are not caught, the stack trace is printed, and that's helpful.)

Occasionally, exc.msg of an Exception doesn't give enough information. So, printing exc (not exc.msg) temporarily to look at the stack trace is helpful.

Ali

1 2
Next ›   Last »