 | |
#21
 
| |||
| |||
|
Re: D3/Linux program abort -
03-05-2007
, 10:44 AM
|
"mwright" wrote: I'm hoping for a MUCH better error msg next time!!!! :^) Glad the issue was resolved, Mark. I have discussions with developers all the time about this sort of thing. The fire is out and the trucks have left the scene, but the same sort of fire could occur anywhere. Most developers are interested in putting out the fire and getting on to the next problem, rather than solving the real problem. No error message, no problem, right? No, find out what allowed someone to walk into a cryptic error and don't allow the code to do that. I frequently petition my vendors to get their software to recognize when something simple has gone wrong, and to provide an appropriate error message so that we can get through diagnostics quickly and get on with our work. For example, don't give us a core dump; recognize that the return value of that last call was a negative number and display an error message, rather than continuing on into code that can't handle that value. There's also the "techno error" that developers tend to display when something in English would be just as appropriate: "KQR89.Z: obj unassgd" makes no sense, where "Value Name cannot be null" makes much more sense. I'll pay 2 cents for the extra vowel but I'd much prefer a real message. And since we're here, I know some people are hesitent to display any sort of error at all. QM provides a flag to disable warnings and Caché doesn't display "var unassigned" errors at all. C'mon folks, when there's a problem we need to know about it! |
abort when accessing undefined
variables, just like the default for CachéObjectScript.
I also hate to have errors hidden from me...
However, it turned out that many important MultiValue customers of
ours ran into problems with that,
because there applications often hit unassigned variables, and
depended on the UniVerse behavior
of displaying a warning message, but returning a empty string and
continuing.
In order for their applications to run, we had to change things so
that CachéMVBasic also just returns
a "" and continues.
I plan on changing this in the future, so that this behavior is
switchable (but haven't gotten around to it quite yet...
I've only been working an average of 80 hours a week for the last 3+
years on this project as it is! :-( )
Scott
P.S. I hope you will appreciate some of the other features of Caché,
you can compile and check the validity of
your PROCs, your I-types, and conversion/correlative codes in MVBasic
programs and in dictionaries, and catch
a lot of errors that you might not have even been aware were lurking
in your application.
#22
| |||
| |||
|
|
"mwright" wrote: I'm hoping for a MUCH better error msg next time!!!! :^) For this br.store.rtn issue, I think it would be difficult to solve the root problem because the code was being asked to do something unusual. In other places in D3 and other products, however, the software can easily recognize invalid conditions and report them way before they get down this low and cause the process to fall to debug or a monitor halt. |
the comment correctly: "The
same one's that were trying to be declared LATER via READV's!!!!")? Or is it
an opened File variable being reassigned? In either event, aborting is a
funny way to resolve it
Chandru
#23
| |||
| |||
|
|
"Tony Gravagno" wrote "mwright" wrote: I'm hoping for a MUCH better error msg next time!!!! :^) For this br.store.rtn issue, I think it would be difficult to solve the root problem because the code was being asked to do something unusual. In other places in D3 and other products, however, the software can easily recognize invalid conditions and report them way before they get down this low and cause the process to fall to debug or a monitor halt. What "unusual" problem might that be? A doubly-declared variable (if I read the comment correctly: "The same one's that were trying to be declared LATER via READV's!!!!")? Or is it an opened File variable being reassigned? In either event, aborting is a funny way to resolve it Chandru |
unusual because it's not something the rest of us trip on every day.
It sounds like something was trashing workspace, blowing the stack, or
doing something weird that by its very nature probably couldn't be
caught. That's just one of those things that can happen with any
software.
More so than other environments, D3 is prone to allowing people to
walk into a problem that will cause a system exception like this. Tom
is right when he says this is a result of the 80/20 factor. I
completely agree that an abort is not an appropriate way to resolve
most errors, and that's what I'm talking about. An engineer wants bad
code to fall into system debug, but in an end-user environment that's
not what we want.
There are many ways to resolve this sort of issue which I won't get
into here. My intent was to comment that there are too many products
in our industry that fail to handle errors in a user-friendly, or even
in an adminstrator-friendly manner. A problem can't be fixed unless
it's pointed out and maybe through this thread someone might review
how they handle errors in their own app. If most of the support calls
coming in mention core dumps, system exceptions, blue screens, hangs,
timeouts, or ask about some cryptic message that no one can understand
without access to source code, then I think something should be done
so that we stop wasting our time trying to figure out low-level
messages when the basic problems are really at a much higher level.
We gonna see you at Spectrum?
T
#24
| |||
| |||
|
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.