Page 1 of 1

Exception global constants

Posted: Fri Aug 07, 2009 10:35 am
by ConvertFromOldNGs
by Craig Shearer >> Mon, 7 Feb 2000 3:12:40 GMT

Every JADE generated exception code should have a meaningful global constant associated with it.

Eg.

JE_KeyAlreadyUsedInDict = 1310
JE_ObjectNotFound = 4
JE_NullObjectReference = 1090

I know it's a big job, but it would save developers from either coding their own ones (which would be different to every other developer's constant names) or worse, using the literal value in their code rather than a constant.

Craig.

Re: Exception global constants, and

Posted: Fri Aug 07, 2009 10:35 am
by ConvertFromOldNGs
by peter fitchett >> Wed, 9 Feb 2000 2:17:00 GMT

Ideally, this could be done as part of publishing a method that
formatted the particular data relevent to each exception - so that
logged exception information was more useful than the proverbial "error detected" message.

Everyone seems to have written their own exception methods that log the data that has been useful in the past. (Hopefully those problems are now fixed.) Unfortunately the next 'hit' will be some other exception, and
we will find that the bit of information required will not be recorded.

I have also seen the 'comprehensive' methods that attempt to format
every possible attribute, no matter what the exception was - resulting
in so much logged data that no-one will read it.

A 'standard' exception method that knew the particular attributes relevent to each exception, maintained as new exceptions were implemented, would be a significant aid to all of us. With this globally available, we could handle the exceptions we wanted, then invoke it to get a formatted string for our exception logging.

peter

Re: Exception global constants, and

Posted: Fri Aug 07, 2009 10:35 am
by ConvertFromOldNGs
by Robert Barr >> Thu, 10 Feb 2000 21:10:47 GMT
I have also seen the 'comprehensive' methods that attempt to format every possible attribute, no matter what the exception was - resulting
in so much logged data that no-one will read it.

These user-developed 'comprehensive' methods also contain their own
bugs. The last thing you want when your critical production system has crashed at midnight is exceptions in your exception handler. Surely the plant is best placed to efficiently develop a facility that is suitably robust as well as completely comprehensive (hey, there's a vote of confidence)