Re: Sub-classing exceptions
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
--
Shriramana Sharma, Penguin #395953
Re: Sub-classing exceptions
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
Re: Sub-classing exceptions
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
Re: Sub-classing exceptions
Checked exceptions are a lie.
Re: Sub-classing exceptions
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
Re: Sub-classing exceptions
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?
--
Shriramana Sharma, Penguin #395953
Re: Sub-classing exceptions
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
Re: Sub-classing exceptions
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.
Re: Sub-classing exceptions
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
Re: Sub-classing exceptions
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
