www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Sub-classing exceptions

reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
In Python I can create my own thin exceptions (i.e. just different type for 
convenience of identification in a catch block, no added functionality) by:

class MyError(ExceptionBaseClass): pass

Even in C++ I can do just:

struct MyException: public std::exception {};

But in D:

$ cat except.d
class MyException: Exception {}
$ dmd -c except.d
except.d(1): Error: class foo.MyException cannot implicitly generate a 
default ctor when base class object.Exception is missing a default ctor

OK so I dig up /usr/include/dmd/druntime/import/object.d: which doesn't have 
a default ctor but does have a user-defined one, which then disables the 
default:

class Exception : Throwable
{
     nogc  safe pure nothrow this(string msg, string file = __FILE__, size_t 
line = __LINE__, Throwable next = null)
}

OK fine but then I didn't get why I had to write that long constructor with 
msg, file, __FILE__ etc every time I subclassed exception, so I did:

$ cat except.d
class MyException: Exception { this() { super(""); } }
void main() { throw new MyException; }

But it didn't give the expected results:

$ dmd except.d
$ ./except
except.MyException except.d(1)
...

... since the line number is wrong. OK so the reason is that the constructor 
which has the default arguments of __FILE__ and __LINE__ is called not at 
line 2 but at line 1 i.e. in the declaration of the subclass.

So I am forced to write out all that stuff with __FILE__ etc yet again:

$ cat except.d
class MyException: Exception { this(string msg = "", string file = __FILE__, 
size_t line = __LINE__) { super("", file, line); } }
void main() { throw new MyException; }

Then I get the desired behaviour:

$ dmd except.d
$ ./except
except.MyException except.d(2)

This is too tortuous, and methinks a mixin is in order, and since I can't do 
anything like the C preprocessor's #X stringizing, I can't declare this as a 
mixin template but have to do a string mixin:

$ cat myexception.d
string ExceptionDeclaration(string newExceptionName, string 
baseExceptionName = "Exception")
{
    return "class " ~ newExceptionName ~ ": " ~ baseExceptionName ~ `{
        this(string msg = "", string file = __FILE__, size_t line = 
__LINE__)
            { super(msg, file, line); }
        }`;
}

void main()
{
    mixin(ExceptionDeclaration("MeaCulpa"));
    try { throw new MeaCulpa; }
    catch (MeaCulpa e) {}
    import std.conv;
    mixin(ExceptionDeclaration("MeaNeueaCulpa", "ConvException"));
    try { throw new MeaNeueaCulpa; }
    catch (MeaNeueaCulpa e) {}
    throw new MeaNeueaCulpa;
}
$ dmd myexception.d
$ ./myexception
myexception.main.MeaNeueaCulpa myexception.d(18)
...

So, any thoughts? Any way this could be improved? Would be nice if that 
mixin got into the standard library somehow...
Oct 15 2015
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, 15 October 2015 at 18:07:24 UTC, Shriramana Sharma 
wrote:
 So, any thoughts? Any way this could be improved? Would be nice 
 if that mixin got into the standard library somehow...
Writing a mixin to create a standard constructor for exception types is trivial. The problem is that you can't document code that's mixed in. So, the constructors wouldn't end up in the documentation. And while it's a bit annoying, copy-pasting the two standard constructors for exceptions is pretty trivial. /++ Params: msg = The message for the exception. file = The file where the exception occurred. line = The line number where the exception occurred. next = The previous exception in the chain of exceptions, if any. +/ this(string msg, string file = __FILE__, size_t line = __LINE__, Throwable next = null) safe pure nothrow { super(msg, file, line, next); } /++ Params: msg = The message for the exception. next = The previous exception in the chain of exceptions. file = The file where the exception occurred. line = The line number where the exception occurred. +/ this(string msg, Throwable next, string file = __FILE__, size_t line = __LINE__) safe pure nothrow { super(msg, file, line, next); } So, while this is annoying, I don't think that it's a huge problem. We probably should have better documentation on it though. However, if we were ever to get ddoc support for mixins, then we could easily write a function to use for mixing in the constructors in exception types. Heck, for exceptions that just have the two standard constructors, we could create a function to provide the code to mix in the whole type declaration. e.g. /++ My exception type. +/ mixin(genExceptionType("MyException")); But as long as you can't put ddoc on mixins or have the ddoc inside a mixin end up in the documentation, we're pretty much out of luck on that count. - Jonathan M Davis
Oct 15 2015
parent reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Jonathan M Davis wrote:

 On Thursday, 15 October 2015 at 18:07:24 UTC, Shriramana Sharma
 wrote:
 So, any thoughts? Any way this could be improved? Would be nice
 if that mixin got into the standard library somehow...
Writing a mixin to create a standard constructor for exception types is trivial. The problem is that you can't document code that's mixed in. So, the constructors wouldn't end up in the documentation. And while it's a bit annoying, copy-pasting the two standard constructors for exceptions is pretty trivial.
Can't we just include the /++ +/ block within the Wysiwyg string in the mixin? Does DDoc not process mixins? Shriramana Sharma.
Oct 15 2015
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, 16 October 2015 at 01:52:12 UTC, Shriramana Sharma 
wrote:
 Jonathan M Davis wrote:

 On Thursday, 15 October 2015 at 18:07:24 UTC, Shriramana 
 Sharma wrote:
 So, any thoughts? Any way this could be improved? Would be 
 nice if that mixin got into the standard library somehow...
Writing a mixin to create a standard constructor for exception types is trivial. The problem is that you can't document code that's mixed in. So, the constructors wouldn't end up in the documentation. And while it's a bit annoying, copy-pasting the two standard constructors for exceptions is pretty trivial.
Can't we just include the /++ +/ block within the Wysiwyg string in the mixin? Does DDoc not process mixins?
ddoc doesn't process mixins. If it did, then mixing in the constructors would work just fine. But because it doesn't, mixing in the constructors only works if you don't care about them being documented, which isn't exactly good practice. - Jonathan M Davis
Oct 15 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-10-15 20:07, Shriramana Sharma wrote:

 $ cat except.d
 class MyException: Exception { this() { super(""); } }
 void main() { throw new MyException; }

 But it didn't give the expected results:

 $ dmd except.d
 $ ./except
 except.MyException except.d(1)
 ...

 ... since the line number is wrong.
I always wondered, if the runtime can get the filename and line numbers for the backtrace, can't it get the same information where the exception was thrown?
 This is too tortuous, and methinks a mixin is in order, and since I can't do
 anything like the C preprocessor's #X stringizing, I can't declare this as a
 mixin template but have to do a string mixin:

 $ cat myexception.d
 string ExceptionDeclaration(string newExceptionName, string
 baseExceptionName = "Exception")
 {
      return "class " ~ newExceptionName ~ ": " ~ baseExceptionName ~ `{
          this(string msg = "", string file = __FILE__, size_t line =
 __LINE__)
              { super(msg, file, line); }
          }`;
 }
I think constructors should be inherited. If you declare the subclass as usual you can have a template mixin that adds the constructor. class SubException : Exception { mixin ExceptionConstructors; } -- /Jacob Carlborg
Oct 16 2015
next sibling parent reply Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Jacob Carlborg wrote:

 On 2015-10-15 20:07, Shriramana Sharma wrote:
 
 $ cat myexception.d
 string ExceptionDeclaration(string newExceptionName, string
 baseExceptionName = "Exception")
 {
      return "class " ~ newExceptionName ~ ": " ~ baseExceptionName ~ `{
          this(string msg = "", string file = __FILE__, size_t line =
 __LINE__)
              { super(msg, file, line); }
          }`;
 }
I think constructors should be inherited.
Yes the constructors are inherited, but the problem, as I illustrated, is that the inherited constructor gets the __FILE__ and __LINE__ data for the point of declaring the exception subclass, and not at the point of throwing it.
 If you declare the subclass as usual you can have a template mixin that
 adds the constructor.
 
 class SubException : Exception
 {
      mixin ExceptionConstructors;
 }
Hmmm is that in any way advantageous to what I wrote about it? Is it just that you can now add a doc-comment that DDoc can recognize? --
Oct 16 2015
next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 10/16/15 10:35 PM, Shriramana Sharma wrote:
 Jacob Carlborg wrote:
 If you declare the subclass as usual you can have a template mixin that
 adds the constructor.

 class SubException : Exception
 {
       mixin ExceptionConstructors;
 }
Hmmm is that in any way advantageous to what I wrote about it? Is it just that you can now add a doc-comment that DDoc can recognize?
You can add other members to your custom exception class. If you wanted for instance to have some specialized toString function, or extra data, you could add. With yours, only simple derived types can be created. -Steve
Oct 16 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-10-17 04:35, Shriramana Sharma wrote:

 Hmmm is that in any way advantageous to what I wrote about it? Is it just
 that you can now add a doc-comment that DDoc can recognize?
Less ugly. You don't have to fiddle with building strings. -- /Jacob Carlborg
Oct 17 2015
parent reply Temtaime <temtaime gmail.com> writes:
Checked exceptions are a lie.
Oct 17 2015
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, 17 October 2015 at 18:00:06 UTC, Temtaime wrote:
 Checked exceptions are a lie.
??? This thread has been about declaring exception classes (many of which have exactly the same constructors and how it's annoying to have to duplicate that boilerplate). You're the first to mention anything about checked exceptions, and I don't see what it has to do with the discussion. - Jonathan M Davis
Oct 17 2015
prev sibling parent Shriramana Sharma <samjnaa_dont_spam_me gmail.com> writes:
Jacob Carlborg wrote:

 If you declare the subclass as usual you can have a template mixin that
 adds the constructor.
 
 class SubException : Exception
 {
 mixin ExceptionConstructors;
 }
https://github.com/D-Programming-Language/druntime/pull/1413 --
Oct 18 2015