Okay, I am back with this topic, because it really makes software maintenance hard and costs a lot of type checking and stuffon exceptions, just to show some useful information to the user and thus give the support staff some kind of useful information for their search for a bug.
What was the problem again?The main problem is that there seems to be no one method across all kinds of exceptions that you can use to display error information. All kinds of signals and exceptions have their user-readable information accessible through different methods.
Why is it a problem?Because if you want to show error information to the user of an application, there is no unique way to say anything more helpful than "An Exception Occured!". The real calories of an exception or signal lie buried in some variable in some embedded Exception's variable. Unfortunately, this variable is not the same for all Exception types, neither within code shipped by Instantiations, nor within 3rd party code.
This is not only a problem for the case where some user out in the field gets an error popup and cannot tell the maintenance guys what actually happened, but even as a developer you often have to dig around in the debugger for a while until you get anything more specific than "Signal on Exception: an exception has occured". This costs real time, nerves and therefor $$$MONEY$$$.
What does Joachim think Instantiations can and should do?
Step 1: Postulate a new standard method that each kind of Signal / Exception should answer with a user-readable and helpful descritpion of the problem.
Step 2: Consolidate all supported frameworks and libraries that ship with VAST to have this standard method answer useful info. This may be by using the individual existing methods that answer the correct string.
Step 2a: Encourage third parties (tool vendors, goodie authors, o/s port maintainers) to implement that new standard method.
What does Joachim think we as a Community can do?We cannot do much about Step 1 other than nagging Instantiations here and in support cases. Once Step 1 is made, we can do a lot about Step 2a: comb through our goodies and ported code and (re-)implement or error handling code.
Why does Joachim think this is of any use to anybody?Because I can't believe I am the only person who is tired of writing lots of [:ex| ex isKindOf: ... ifTrue:[] ifFalse: []] cascades in handlers and still having lots of cases where the application simply says: "I know something went wrong but I won't tell you!"
Maybe many projects out there that have existed for 15 years or more have their own solutions for this kind of problem (one giant bloated block filled with ifTrue:s, but for
new projects this is just another expensive hurdle that needs to be taken. A simple thing gets hard and tiresome in the existing code base.
Thanks for reading and commenting
Joachim