On 2/12/2014 6:14 PM, Sean Kelly wrote:
On Wednesday, 12 February 2014 at 22:42:45 UTC, Nick Sabalausky
wrote:
Tried on both 2.064.2 and 2.065-b3.
Could it be that the custom toString just doesn't get run for static
exceptions?
It should. I'm not entirely sure why it isn't working. For
On 2/13/2014 2:55 AM, Nick Sabalausky wrote:
But if I use the RDMD/DMD *both* from DMD 2.065-b3
then...I dunno, either the exe doesn't get actually get rebuilt even
with --force, or maybe it does but then runs an older copy of the exe,
or something screwy like that. I need to look into that
On Wednesday, 12 February 2014 at 02:41:34 UTC, Nick Sabalausky
wrote:
On 2/11/2014 6:35 PM, Sean Kelly wrote:
Throw a static exception (maybe even derived directly from
Throwable),
I assume then that throwing something directly derived from
Throwable would still run cleanup code (like scope
On Wednesday, 12 February 2014 at 03:31:38 UTC, Nick Sabalausky
wrote:
Hmm, my custom toString isn't being executed. Am I doing
something wrong here? Same result if I inherit direct from
Throwable instead of Exception.
class Fail : Exception
{
private this()
{
super(null);
On Wednesday, 12 February 2014 at 22:42:45 UTC, Nick Sabalausky
wrote:
Hmm, that still isn't getting called for me either:
void toString(scope void delegate(in char[]) sink) const
{
import std.stdio;
writeln(In Fail.toString());
sink(someapp: ERROR: ~msg);
}
Tried on both 2.064.2 and
On Tuesday, 11 February 2014 at 03:53:05 UTC, Nick Sabalausky
wrote:
I don't suppose there's a way to change the default exception
handler without using a modified druntime
I'm pretty sure there used to be, but not anymore looking at the
source. The d_run_main function has a hardcoded catch
I don't suppose there's a way to change the default exception handler
without using a modified druntime? I'm not seeing one in the docs, but I
could have overlooked something.
Replacing a druntime function at link-time wouldn't be ideal because
then druntime's handler couldn't be called as a
On 2/10/2014 10:57 PM, Adam D. Ruppe wrote:
On Tuesday, 11 February 2014 at 03:53:05 UTC, Nick Sabalausky wrote:
I don't suppose there's a way to change the default exception handler
without using a modified druntime
I'm pretty sure there used to be, but not anymore looking at the source.
The
On Tuesday, 11 February 2014 at 05:09:13 UTC, Nick Sabalausky
wrote:
mixin(handleFail!(() = {
...user code...
}));
BTW the ()= there is unnecessary; when there's no arguments, you
can just write { code } and it will be recognized as a
function/delegate. So this would work
On 2014-02-11 06:09, Nick Sabalausky wrote:
I don't strictly *need* to. But if you're curious, here's the story:
I like to use a little custom exception (Fail) in shell script-like
stuff to bail out and exit with a given error message in an
exception-safe way. This is for expected failure
On 2/11/2014 10:00 AM, Adam D. Ruppe wrote:
So this would work too:
int handleError(void delegate() dg) {
try dg();
catch(Throwable t) return 1;
return 0;
}
int main() {
return handleError({
});
}
Oh yea, good point. That's not bad at all;
Adam D. Ruppe:
int handleError(void delegate() dg) {
try dg();
catch(Throwable t) return 1;
Is it possible to use a lazy argument there? And isn't it better
to catch Exception only?
Bye,
bearophile
On 2/11/2014 6:35 PM, Sean Kelly wrote:
Throw a static exception (maybe even derived directly from Throwable),
similar to OutOfMemory, with a custom toString. That should eliminate
the formatting you don't like and will prevent the trace from occurring
as well (see rt/deh.d in Druntime--the
On Wednesday, 12 February 2014 at 01:07:31 UTC, Nick Sabalausky
wrote:
Oh, interesting. Is this something that can be relied on
long-term? Ie, is a static non-Exception Throwable deliberately
*supposed* to not include a stack trace, or is it potentially
more of a currently-missing feature?
On Wednesday, 12 February 2014 at 01:08:42 UTC, bearophile wrote:
Is it possible to use a lazy argument there?
I think it depends on the task. To just wrap generic code though
a delegate seems most straightforward.
And isn't it better to catch Exception only?
Perhaps, or the specific
On 2/11/2014 6:35 PM, Sean Kelly wrote:
Throw a static exception (maybe even derived directly from Throwable),
I assume then that throwing something directly derived from Throwable
would still run cleanup code (like scope guards and finally) like
throwing Exception would? Or is it like
On 2/11/2014 6:35 PM, Sean Kelly wrote:
Throw a static exception (maybe even derived directly from Throwable),
similar to OutOfMemory, with a custom toString. That should eliminate
the formatting you don't like and will prevent the trace from occurring
as well (see rt/deh.d in Druntime--the
17 matches
Mail list logo
