Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!decwrl!sgi!tarolli@riva.esd.sgi.com
From: tarolli@riva.esd.sgi.com (Gary Tarolli)
Newsgroups: comp.sys.sgi
Subject: Re: shademodel
Summary: why lousy error messages
Keywords: GL
Message-ID: <51153@sgi.sgi.com>
Date: 19 Feb 90 16:57:22 GMT
References: <2548@fs1.cam.nist.gov> <50750@sgi.sgi.com> <1990Feb19.064953.2125@cs.UAlberta.CA>
Sender: tarolli@riva.esd.sgi.com
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 46


	.
	.
	.

> Yep, this sounds like the right explanation, but what really bothers me is
> WHY CAN'T WE GET MEANINGFUL ERROR MESSAGES????? 
>   Something like 'Illegal call with no window open' would help users to
> solve a problem without beating their head against a wall or calling the
> hotline.  If it's possible to identify the graphics call that's blowing 
> up, then this helps even more.
> 
>   Since your documentation doesn't always clearly state what can, or cannot
> be called before a window open (hint, hint!), there is even more reason
> to encourage reasonable error messages.
> 

The graphics call that blew up can be identified by using dbx on the core
file.  A stack track should readily identify the offending routine.  As for
the error messages, here's the reason.  Some of the GL calls, eg. v3f have
to be called at a very rapid rate (> 1 million per second) to achieve the
graphics performance the hardware can deliver.  Putting in something as simple
as an "if" test and worse yet a subroutine call (even if its not taken it will
make the routine a non-leaf routine which adds lots of code to the procedure's
entry and exit code), will seriously degrade performance.  Although there are
many routines that are not performance critical, there are also many many
things to test for.  The code would not be easy to implement - imagine the
problem of checking for a valid pointer - you should really try to access
the data while catching segv signals - but what if the user is also catching
segv signals? etc etc.

However, your point is valid - we need better error messages and parameter
checking.  Rather than add code to the GL, most of us would prefer to build
an alternate GL that could be used for debugging.  THus the performance of
the real GL would not be affected.  This debugging GL would only be used
while debugging.  It could be implemented as a separate library, for those
who don't use the shared lib, or as a "somehow switchable" part of the 
shared library that could be activated when desired, or as a DGL filter.
We have many options here, however I cannot promise anything soon.  Make
your voice heard by calling the HOTLINE and requesting 2 things:
	1) a GL error message/debugging guide, preferrably 50-100 pages worth
	2) a version of the GL library that does error checking as
		described above.

--
						Gary Tarolli