Re: how to make this function nothrow?
On Tuesday, 16 February 2021 at 00:39:33 UTC, Steven Schveighoffer wrote: On 2/15/21 4:04 PM, Jack wrote: I have to make my function nothrow because the function that calls it (not written by me) is nothrow. So I need to wrap my code in a try-catch() but how will I report the error message, if the toString() from Throwable isn't nothrow? how do I get out this circular dependence? void f() nothrow { import std.conv : to; try { // do something } catch(Throwable th) { auto err = th.toString; } } I can't use err variable, it result in error: function object.Throwable.toString is not nothrow obviously, insert a try-catch() within catch() is a circular dependence and doesn't solve the problem either (even if it, I think it would be quite ugly) https://dlang.org/phobos/std_exception.html#assumeWontThrow import std.exception; auto err = assumeWontThrow(th.toString, "oops, toString threw something!"); -Steve I didn't know about that function, I'll be using this one from now. Thanks! Adam and Ali thank you guys too, helpful always
Re: how to make this function nothrow?
On 2/15/21 4:04 PM, Jack wrote: I have to make my function nothrow because the function that calls it (not written by me) is nothrow. So I need to wrap my code in a try-catch() but how will I report the error message, if the toString() from Throwable isn't nothrow? how do I get out this circular dependence? void f() nothrow { import std.conv : to; try { // do something } catch(Throwable th) { auto err = th.toString; } } I can't use err variable, it result in error: function object.Throwable.toString is not nothrow obviously, insert a try-catch() within catch() is a circular dependence and doesn't solve the problem either (even if it, I think it would be quite ugly) https://dlang.org/phobos/std_exception.html#assumeWontThrow import std.exception; auto err = assumeWontThrow(th.toString, "oops, toString threw something!"); -Steve
Re: how to make this function nothrow?
On 2/15/21 1:04 PM, Jack wrote: > I have to make my function nothrow because the function that calls it > (not written by me) is nothrow. So I need to wrap my code in a > try-catch() but how will I report the error message, if the toString() > from Throwable isn't nothrow? how do I get out this circular dependence? I understand that the caller is not written by you but I hope it at least expects an 'int' code from f(). The following "last error" is a common way for no-exception languages like C. I put the fprintf in g() but you can put it at a higher level that you control. You can print fLastError when g() fails. string fLastError; int f() nothrow { import std.conv : to; fLastError = null; try { "hi".to!int; } catch(Throwable th) { import std.format; fLastError = __FUNCTION__ ~ " failed: " ~ th.msg; return 1; } return 0; } int g() nothrow { const err = f(); if (err) { import core.stdc.stdio : fprintf, stderr; fprintf(stderr, "%.*s\n", cast(int)fLastError.length, fLastError.ptr); } return err; } int main() { return g(); } Ali
Re: how to make this function nothrow?
On Monday, 15 February 2021 at 21:04:50 UTC, Jack wrote: obviously, insert a try-catch() within catch() is a circular dependence and doesn't solve the problem either (even if it, I think it would be quite ugly) well that's prolly the way to do it, just catch Exception and like assert(0) if it happens with a static string assert(0, "exception toString threw"); to completely abort at that point.
how to make this function nothrow?
I have to make my function nothrow because the function that calls it (not written by me) is nothrow. So I need to wrap my code in a try-catch() but how will I report the error message, if the toString() from Throwable isn't nothrow? how do I get out this circular dependence? void f() nothrow { import std.conv : to; try { // do something } catch(Throwable th) { auto err = th.toString; } } I can't use err variable, it result in error: function object.Throwable.toString is not nothrow obviously, insert a try-catch() within catch() is a circular dependence and doesn't solve the problem either (even if it, I think it would be quite ugly)