www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - List of exceptions?

reply DMon <no mail.com> writes:
Is there a list of a list of the exceptions or what can be used 
with catch?

I'm thinking that I missed it and there is something easier than 
breaking old code, scouring the site, or hypnotic regression.
Oct 10 2020
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 10/10/20 5:12 AM, DMon wrote:

 Is there a list of a list of the exceptions or what can be used with catch?
 
 I'm thinking that I missed it and there is something easier than 
 breaking old code, scouring the site, or hypnotic regression.


Only Throwable and classes that are derived from it can be thrown and 
caught.

It has two decendants:

    Throwable
     /     \
  Error   Exception

Throwable and Error are caught very rarely in special situations. For 
example, a thread may catch all types of exceptions to report the reason 
why it's about to die.

So the only type that is and should be used in most programs is Exception:

void main() {
   try {
     foo();

   } catch (Exception e) {
     writefln!"Something bad happened: %s"(e.msg);

     // You can continue if it makes sense
   }
}

So, programs base their exceptions on Exception:

class MyException : Exception {
   this(int i) {
     import std.format;
     super(format!"Bad int happened: %s"(i));
   }
}

void foo() {
   throw new MyException(42);
}

void main() {
   foo();
}

There are helpers in std.exception e.g.

class MyException : Exception {
   import std.exception;
   mixin basicExceptionCtors;
}

void foo() {
   throw new MyException("a problem happened");
}

void main() {
   foo();
}

I have some basic information here:

   http://ddili.org/ders/d.en/exceptions.html

Ali
Oct 10 2020
parent reply DMon <no mail.com> writes:
On Saturday, 10 October 2020 at 14:56:31 UTC, Ali Çehreli wrote:

 On 10/10/20 5:12 AM, DMon wrote:

 Is there a list of a list of the exceptions or what can be 
 used with catch?


 Only Throwable and classes that are derived from it can be 
 thrown and caught.

 Ali


Thanks for the reply.

I am looking to catch exceptions explicitly and get that it does 
not have to be. Is explicite cathing the best practice or is 
implicite how its done?
Oct 10 2020
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 10/10/20 8:46 AM, DMon wrote:

 On Saturday, 10 October 2020 at 14:56:31 UTC, Ali =C3=87ehreli wrote:

 On 10/10/20 5:12 AM, DMon wrote:

 Is there a list of a list of the exceptions or what can be used with =







 catch?


 Only Throwable and classes that are derived from it can be thrown and =





 caught.

 Ali


=20
 Thanks for the reply.
=20
 I am looking to catch exceptions explicitly and get that it does not=20
 have to be. Is explicite cathing the best practice or is implicite how =



 its done?


I don't know implicit catching. I would like to learn from others.

I think the common rules are:

- Don't catch anything
- Unless you can do something about it (e.g. ask the user something to=20
retry, augment it, etc.)

I almost always catch in main() (or a thread's main function) and only=20
to print a clean error message:

void main() {
   try {
     // ...

   } catch (Exception e) {
     stderr.writefln!"ERROR: %s"(e.msg);
   }
}

That's it for me. :)

Ali
Oct 10 2020
parent reply DMon <no mail.com> writes:
On Saturday, 10 October 2020 at 16:00:26 UTC, Ali Çehreli wrote:

 On 10/10/20 8:46 AM, DMon wrote:

 On Saturday, 10 October 2020 at 14:56:31 UTC, Ali Çehreli 
 wrote:

 On 10/10/20 5:12 AM, DMon wrote:

 Is there a list of a list of the exceptions or what can be 
 used with catch?


 Only Throwable and classes that are derived from it can be 
 thrown and caught.

 Ali


 Is explicite cathing the best practice or is implicite how its 
 done?


 I don't know implicit catching. I would like to learn from 
 others.

 Ali


Maybe those are the wrong words.
catch (Exception e) // implicit (any exception)
catch (ConvException f) // explicit (conversion only)

Or is that not correct?

You wrote a book and I'm typing snippets.
Oct 10 2020
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 10/10/20 9:16 AM, DMon wrote:


 catch (Exception e) // implicit (any exception)
 catch (ConvException f) // explicit (conversion only)

 Or is that not correct?


I think in class hierarchies, "more general" and "more specific" are 
better terms. :)

The answer is, catch by the most general under the Exception hierarchy 
that you care about. It depends on the program. In most of my programs, 
catching Exception in main is sufficient because I just print the error 
message.

However, sometimes the error message does not make sense at that level:

void foo() {
   // The error thrown during this may not be meaningful to
   // the user of the program:
   // "Unexpected 'h' when converting from type string to type int"
   "hello".to!int;
}

So, you can augment that error with another one:

import std.conv;
import std.stdio;
import std.format;

class FooException : Exception {
   string msg;
   Exception actual;

   this (Exception e) {
     this.msg = format!"Failed to do foo: %s"(e.msg);
     super(this.msg);
     this.actual = e;  // Store for more information later
   }
}

void foo() {
   try {
     "hello".to!int;

   } catch (Exception e) {
     // Convert to a more meanigful exception:
     throw new FooException(e);
   }
}

int main() {
   try {
     foo();

   } catch (Exception e) {
     stderr.writefln!"ERROR: %s"(e.msg);
     return 1;
   }

   return 0;
}

One cool thing about storing the 'actual' exception is, you can later 
debug it by catching the specific FooException and printing 'actual' as 
is, which contains the stack trace:

int main() {
   try {
     foo();

   // Added for debugging:
   } catch (FooException e) {
     // Printing as is contains the stack trace:
     stderr.writeln(e.actual);
     return 1;

   } catch (Exception e) {
     stderr.writefln!"ERROR: %s"(e.msg);
     return 1;
   }

   return 0;
}

But really, it all depends on your program. The simplest thing may to 
not catch at all. The default behavior is to dump the stack trace and it 
works for some programs.

Ali
Oct 10 2020
parent reply DMon <no mail.com> writes:
On Saturday, 10 October 2020 at 18:16:45 UTC, Ali Çehreli wrote:

 On 10/10/20 9:16 AM, DMon wrote:


 catch (Exception e) // implicit (any exception)
 catch (ConvException f) // explicit (conversion only)

 Or is that not correct?


 I think in class hierarchies, "more general" and "more 
 specific" are better terms. :)

 The answer is, catch by the most general under the Exception 
 hierarchy that you care about. It depends on the program. In 
 most of my programs, catching Exception in main is sufficient 
 because I just print the error message.

 However, sometimes the error message does not make sense at 
 that level:

 So, you can augment that error with another one:

 One cool thing about storing the 'actual' exception is, you can 
 later debug it by catching the specific FooException and 
 printing 'actual' as is, which contains the stack trace:

 But really, it all depends on your program. The simplest thing 
 may to not catch at all. The default behavior is to dump the 
 stack trace and it works for some programs.

 Ali


I will copy that down.

The idea for specific exceptions came from the online docs and 
Programing in D, 39.2 The try-catch statemet

try
{ // the code block that is being executed, where an // exception 
may be thrown
}
catch (an_exception_type)
{ // expressions to execute if an exception of this // type is 
caught
}
catch (another_exception_type)
{ // expressions to execute if an exception of this // other type 
is caught // ... more catch blocks as appropriate ...
}
finally
{ // expressions to execute regardless of whether an // exception 
is thrown
}


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
//

int main()
{


     string z1 = "+ "; string z2 = "++ ";
     bool a1 = false; bool a2 = true;
     int b1 = 0; int b2 = 1;
     uint c1 = 0; uint c2 = 1;
     float d1 = 1f; float d2 = 2f;
     char e1 = 'a'; char e2 = 'b';

     int o1; int o2;

//    auto test;
     int[3] ar1; int[5] ar2;
     string st1 = "arg";


     writeln("Control\n\n");

/*
     writeln("Testing");
     try
     {
         writeln(z1 ~ e1 ~ st1);
         writeln();
     }
     catch (Exception y1)
     {
         writeln("Something ", y1.msg,
                               y1.info);
     }
*/


     writeln("try...catch");
     try
     {
         o1 = to!int("hello");

     }
     catch (Exception i1)
     {
         writefln(z1 ~ "Message from exception i1: %s", i1.msg);
         writefln(z1 ~ "Info from exception i1: %s", i1.info);
     }
     writeln();

     writeln("try...finally");
     try // Will run as normal code.
     {
         o1 = a2 + b2;
         writeln(z1 ~ "", o1);
     }
     finally
     {
         writeln("Continues to run normally and no exceptions are 
displayed.");
     }
     writeln();

     writeln("try...catch...finally");
     try
     {
           to!int(z1);
           to!int(z2);
     }
     catch (ConvException j1)
     {
         writefln(z1 ~ "1st Exception msg: %s", j1.msg);
         writeln();
     }
     catch (Exception k1)
     {
         writeln(z1 ~ "2nd Exception msg: %s", k1.msg);
     }
     finally
     {
         writeln(z1 ~ "There are two exceptions.");
         writeln(z2 ~ "The first exception is caught and that, 
immediately, exits the try clause.");
     }
     writeln("This still runs.");
     writeln();


/*
     writeln("Nesting");
     try
     {
*/
     return 0;

}
Oct 10 2020
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 10/10/20 12:51 PM, DMon wrote:


 I will copy that down.

 The idea for specific exceptions came from the online docs and
 Programing in D, 39.2 The try-catch statemet

 try
 { // the code block that is being executed, where an // exception may be
 thrown
 }
 catch (an_exception_type)
 { // expressions to execute if an exception of this // type is caught
 }
 catch (another_exception_type)
 { // expressions to execute if an exception of this // other type is
 caught // ... more catch blocks as appropriate ...
 }
 finally
 { // expressions to execute regardless of whether an // exception is 


thrown

 }


I don't have time right now to write longer but I see how that can be 
confusing and apologize for the confusion. :(

In general, forget all of that and just catch Exception. :) That's all 
you need. And 'finally' is almost never used in D.

Ali
Oct 10 2020
parent reply DMon <no mail.com> writes:
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.
Oct 10 2020
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
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 :)
Oct 10 2020
prev sibling parent reply Dominikus Dittes Scherkl <dominikus scherkl.de> writes:
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.
Oct 12 2020
next sibling parent DMon <no mail.com> writes:
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.
Oct 12 2020
prev sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
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
Oct 12 2020
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 10 October 2020 at 12:12:35 UTC, DMon wrote:

 Is there a list of a list of the exceptions or what can be used 
 with catch?

 I'm thinking that I missed it and there is something easier 
 than breaking old code, scouring the site, or hypnotic 
 regression.


To clarify, do you want a list of *possible* exceptions, like in 
Java?
Oct 10 2020
parent DMon <no mail.com> writes:
On Saturday, 10 October 2020 at 16:37:23 UTC, Imperatorn wrote:

 On Saturday, 10 October 2020 at 12:12:35 UTC, DMon wrote:
 To clarify, do you want a list of *possible* exceptions, like 
 in Java?


Please.

I've been looking and thinking that I'm over complicating it for 
myself so it may not be necessary. Instead use multiples of 
catch(Exception var) and writefln(var.some_method, 
var.another_method) for multiple exceptions.
Oct 10 2020