Is there always MTOWTDI?

In jettero's recent post, STDERR, he was attempting to solve a problem that wasn't really a problem. Or, in short, his own answer to his problem was a singular effective solution which may introduce further problems if a case exists where he doesn't want to have a certain action associated with warnings. Admittedly, he can simply override the action and restore it after he handles the warning in the other manner. But it got me to thinking if this was a good way to handle it.

I was actually asked by footpad to take a look at the thread and to see if any good answers had been posted (most notably his :). That's why I posted Re: STDERR. I felt that in the overwhelming rush to find an answer, everybody overlooked the fact that the warnings were being produced from failed database statements via the DBI. Furthermore, the DBI already has mechanisms in place to handle errors (and this is where my answer came from).

So, I think the questions I want to ask are as follows:

If you select a module as the way you're going to do it, have you effectively chosen to limit yourself, in regards to the task the module performs, of the ways by which you attempt to solve your tasks?
What takes precedent, the API defined by the module or the spec which says do X with all errors? In essence, I tend to use the $DBI::errstr when it is populated to determine action, but why aren't there hooks in the connect string to allow overridden exceptions? (rhetorical question...)

What do/have you thought about the self imposed restrictions when using well defined modules with good APIs? Is it always necessary to follow the rules? Is it better to follow just in case you forget why you broke them?

ALL HAIL BRAK!!!

Comment on Is there always MTOWTDI?

Replies are listed 'Best First'.
Re: Is there always MTOWTDI? by footpad (Abbot) on Dec 20, 2000 at 10:32 UTC
The apprentice, noting his name taken in vain, hazards this reply... A qualified yes... As with Perl itself, doesn't the real answer depend on the specific context? We saw three (or four, depending on who's counting) different ways to tackle the problem. I admit, your approach best fit the actual context. I can imagine other contexts where the other approaches might offer advantages. Certainly it makes sense to use a module's error handling facilities when possible. However, my work with the Windows API (yes, I know it sucks, but there you are.) suggests that there are times when a selective use of a library's features can provide more than the original designer thought could (or should) be made made available (or documented). That suggests, of course, a certain level of familiarity of said API...and a certain level of mastery over the implementation. Not to mention (something us Win folk are still amazed at), access to source (or, as is more common for us, access to definitions via header files). In turn, it suggests that unless you feel confident that you have said familiarity, you should defer to the module's author, as that's really the whole point of modules. Isn't it? Follow another, more experienced person's footsteps to benefit from their experience, knowlege, and agony? And, should you choose to break the rules or do something really tricky, please, please, oh PLEASE document it in comments so lesser mortals can see (and follow) your wisdom... --f P.S. Sorry...that's a sore spot at the moment. It'll heal; promise...	[reply]
Re (tilly) 2: Is there always MTOWTDI? by tilly (Archbishop) on Dec 20, 2000 at 20:46 UTC
Be very, very careful. Relying on the details of someone else's implementation is a very bad thing to do. Oh, lots of people do it. It works. But it leads to extra complexity, potential problems with future changes to the library, etc, etc, etc. In general assume that anything not explicitly documented can and will change. Work with the interface whereever possible. Anything which pokes around in internals you have no business accessing should be regarded as probable future breakage. And remember that modular code is broken into components, each of which has a simple interface to the outside world. Keep your interfaces simple and clean, only use those interfaces. you will save a lot of headaches...	[reply]
Re: Re: Is there always MTOWTDI? by PsychoSpunk (Hermit) on Dec 20, 2000 at 22:24 UTC
footpad, in the case of the Windows API, you suggest selective use of the library's features. But unless you are writing your own interfaces to access the internals, you're still playing by the rules. I would wager that you still have to use the interfaces to get at the internal data, but you do so in unique ways in which the developer didn't imagine. That's the job of a developer. Provide all the methods that are necessary to get to the needed information, but as the developer you can never know how this is going to be used. This is the human side of encapsulation, often seen in the situation where the manager hands you a ream of paper and says, "Do this." You just do it, without knowing who's going to do what with it. Of course, this is an extreme model, but it happens. My big point is that unlike a real OO language (touchy subject I know, but in a comparative sense), Perl doesn't hold these restrictions over our head when it's running a script. We have to take charge and hold these restrictions on ourselves if we choose to develop with a certain API. tilly may have pointed out the best reason why, even though it's unlikely that certain actions (such as our lovely RaiseError producing warnings) will change, we can't assume that they won't. ALL HAIL BRAK!!!	[reply]