Sounds pretty reasonable. For backward compatibility, it should
probably be done as a hook type setting... if the hook is called and
provides an error handler, then the error handler is used, otherwise the
message box gets displayed. And maybe the error handler returns a value
that says whether it handled it or not, and if not, the message box gets
displayed then too.
Of course, a nicer enhancement would be if the error messages were more
directly related to the error that occurred. A reference to an
undefined value "somewhere" in an XS function call is less useful than
one that would pinpoint the variable of interest, and the line of code.
Maybe such enhancements are impossible, but I know from experience
that eliminating a couple such references from Win32::GUI was like
looking for a needle in a haystack.
On approximately 12/20/2003 5:53 AM, came the following characters from
the keyboard of Jez White:
All,
Would anyone find a generic error handler useful? Instead of win::gui
displaying the message box when an error occurs it would instead call a
function passing in the error string. This would allow the application
to do logging or respond in other ways.
Thoughts?
Cheers,
jez.
--
Glenn -- http://nevcal.com/
===========================
Like almost everyone, I receive a lot of spam every day, much of it
offering to help me get out of debt or get rich quick. It's ridiculous.
-- Bill Gates
And here is why it is ridiculous:
The division that includes Windows posted an operating profit of $2.26
billion on revenue of $2.81 billion.
--from Reuters via
http://biz.yahoo.com/rc/031113/tech_microsoft_msn_1.html
So that's profit of over 400% of investment... with a bit more
investment in Windows technology, particularly in the area of
reliability, the profit percentage might go down, but so might the bugs
and security problems? Seems like it would be a reasonable tradeoff.
WalMart earnings are 3.4% of investment.
