View mode: basic / threaded / horizontal-split · Log in · Help
March 05, 2012
Re: dereferencing null
On Mon, 05 Mar 2012 10:43:22 +0100, David Nadlinger <see@klickverbot.at>  
wrote:

> On Monday, 5 March 2012 at 09:09:30 UTC, Jacob Carlborg wrote:
>> On 2012-03-05 07:25, Walter Bright wrote:
>>> […]
>>> run (run your program)
>>> bt (print a backtrace)
>>> quit (exit gdb)
>>> […]
>> Is demangling supposed to work on Mac OS X?
>
> As the D demangling support was added in GDB 7.<something>,  
> unfortunately no, as Apple ships an ancient (customized) version.
>
> David

From GDB7.3 OSX MACH-O support is somewhat fixed, but it's buggy when being
used with dmd because it doesn't relocate the "__textcoal_nt" sections.
March 05, 2012
Re: dereferencing null
Personally I'd love to get more info about out-of-bounds errors. E.g.
for arrays, which index the code attempted to access, and for hashes
which key.

Sure it's easy to use an enforce, but I'd rather have that inserted in
debug builds with bounds checking anyway. For example:

void main()
{
   int[int] aa;
   int key = 1;
   auto a = aa[key];
}

core.exception.RangeError@test(22): Range violation

That's not too much information (well there's also that stacktrace
which is still broken on XP regardless of dbghelp.dll). This is
better:

import std.exception;
import core.exception;

void main()
{
   int[int] aa;
   int key = 1;
   enforce(key in aa, new RangeError(format(": Key %s not in hash. ", key)));
   auto a = aa[key];
}

core.exception.RangeError@: Key 1 not in hash. (20): Range violation

I'd rather not have to depend on debuggers or code duplication (even
mixins) for this basic information.

Side-note: RangeError is missing a constructor that takes a *message*
as the first parameter, the one that was called takes a file string
parameter. With the ctor fixed the error becomes:
core.exception.RangeError@test.d(20): Range violation: Key 1 not in hash.

That would help me so much without having to change code, recompile,
and then wait 20 seconds at runtime to reach that failing test again.
March 05, 2012
Re: dereferencing null
On Fri, 02 Mar 2012 10:19:13 -0500, deadalnix <deadalnix@gmail.com> wrote:

> Le 02/03/2012 15:37, Jacob Carlborg a écrit :
>> Isn't it quite unsafe to throw an exception in a signal ?

One does not need to throw an exception.  Just print a stack trace.  I've  
advocated for this multiple times.  I agree it costs nothing to implement,  
and who cares about safety when the app is about to crash?!

> The signal handler is called on top of the stack, but the information to  
> retrieve the stack trace are system dependant. BTW, using lib like  
> libsigsegv can help a lot to make it safe. It isn't safe ATM, but it is  
> doable.

libsigsegv is used to perform custom handling of page faults (e.g. loading  
pages of memory from a database instead of the MMC).  You do not need  
libsigsegv to handle SEGV signals.

-Steve
March 05, 2012
Re: dereferencing null
On Mon, Mar 05, 2012 at 02:30:14PM +0100, Andrej Mitrovic wrote:
> Personally I'd love to get more info about out-of-bounds errors. E.g.
> for arrays, which index the code attempted to access, and for hashes
> which key.

Personally, I'd love to see D's added string capabilities put to good
use in *all* exception messages. It's been how many decades since the
first C compiler was written? Yet we still haven't moved on from using
static strings in Exceptions. This is silly. A "file not found"
exception should tell you what the offending filename is. It's as simple
as:

	throw new IOException("File '%s' not found".format(filename));

A range violation should say what the offending index was:

[...]
>     enforce(key in aa, new RangeError(format(": Key %s not in hash. ", key)));
[...]
> core.exception.RangeError@: Key 1 not in hash. (20): Range violation

A numerical conversion error should say what the offending malformed
number was. Or at least, include the non-digit character that it choked
on.

A syntax error in getopt should tell you what the offending option was.
(How'd you like it if you ran some random program, and it says "command
line error" with no indication at all of what the error was?)

It's pure common sense. I mean, if the only message dmd ever gave was
"syntax error" without telling you *what* caused the syntax error or
*where* (file, line number, perhaps column), we'd all be beating down
Walter's door. So why should exceptions in other applications be any
different?


T

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula: pi zz a. -- Wouter Verhelst
March 05, 2012
Re: dereferencing null
On Monday, 5 March 2012 at 06:19:53 UTC, Chad J wrote:
> That's cool.  Maybe someone should stick it in Phobos?

I just made a patch and sent it up. It'll have to be
reviewed by the others, but I expect we'll have something
in std.typecons for the next release.

> I also didn't know about @disabled; that's a nifty addition.

Yeah, we brought it up one of the previous null
discussions, and Walter+Andrei liked it as a general
solution to enable this and other checks, like ranged
integers.

Still somewhat new, though; havn't realized all its
potential yet.
March 05, 2012
Re: dereferencing null
On 3/5/12, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
<snip>

Yep, agreed with everything you've said.

Also, I find your message signatures amusing. :P
March 05, 2012
Re: dereferencing null
Le 05/03/2012 15:26, Steven Schveighoffer a écrit :
> On Fri, 02 Mar 2012 10:19:13 -0500, deadalnix <deadalnix@gmail.com> wrote:
>
>> Le 02/03/2012 15:37, Jacob Carlborg a écrit :
>>> Isn't it quite unsafe to throw an exception in a signal ?
>
> One does not need to throw an exception. Just print a stack trace. I've
> advocated for this multiple times. I agree it costs nothing to
> implement, and who cares about safety when the app is about to crash?!
>
>> The signal handler is called on top of the stack, but the information
>> to retrieve the stack trace are system dependant. BTW, using lib like
>> libsigsegv can help a lot to make it safe. It isn't safe ATM, but it
>> is doable.
>
> libsigsegv is used to perform custom handling of page faults (e.g.
> loading pages of memory from a database instead of the MMC). You do not
> need libsigsegv to handle SEGV signals.
>
> -Steve

No you don't, but if you want to know if you are facing a stackoverflow 
or a null deference for exemple, this greatly help the implementation.
March 05, 2012
Re: dereferencing null
On 3/5/2012 4:27 AM, Jacob Carlborg wrote:
> On 2012-03-05 11:38, Walter Bright wrote:
>> Notably, C and C++ do not do what you suggest.
>
> Just because C and C++ do something in a certain way doesn't make it a valid
> reason to do the same thing in D.
>
> I think this is an argument we need to stop using immediately. It just shows
> we're stuck in our ways, can't innovate and can't think for our self.


Doing things differently than well established practice requires a strong 
reason. There are often good reasons for that established practice that aren't 
obvious.
March 05, 2012
Re: dereferencing null
On 3/5/2012 8:07 AM, H. S. Teoh wrote:
> A "file not found" exception should tell you what the offending filename is.

std.file.read("adsfasdf") gives:

std.file.FileException@std\file.d(305): adsfasdf: The system cannot find the 
file specified.
March 05, 2012
Re: dereferencing null
On Mon, Mar 05, 2012 at 11:06:40AM -0800, Walter Bright wrote:
> On 3/5/2012 8:07 AM, H. S. Teoh wrote:
> >A "file not found" exception should tell you what the offending filename is.
> 
> std.file.read("adsfasdf") gives:
> 
> std.file.FileException@std\file.d(305): adsfasdf: The system cannot
> find the file specified.

That's good to know. I just picked "file not found" as my favorite
whipping boy. :-) Now we just need this consistently across all the
standard exceptions. The including the wrong parameter part, not the
whipping part.


T

-- 
Today's society is one of specialization: as you grow, you learn more
and more about less and less. Eventually, you know everything about
nothing.
3 4 5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home