7.20.2011

Some signs of life

I wasn't that active the last time and noticed a few posts I saved someday on my harddisk, but never actually posted them here. However, I want to change that in the feature and will try to keep my thoughts as fresh and immediate as possible and not just dumping them somewhere like used condoms or porn magazines (well, some people might extend that to partners or people in general, which's a quite unnice thing to say the least). However, one of the things that came to my mind quite surprisingly is the fact that so many libraries have some kind of error retrieval in case something happened, but most of them don't keep those consistent or even covering enough. I prefer not storing any error due the necessacity of static or atleast some temporary variables. But I can't deny that sometimes you need store a list of errors that happened while a function does it's work. Youd store in an internal list or last error variables or so - something with which the library user can get in the know of what's going on without having to parse string messages meant for the console or so. When writing OOP classes for Uni assignments I prefer having either the approach that users should archieve them on there own or that there's some kind of error storage like a list or so they can export to an array or whatever if something bad happened. It's a simple and clean way to not forget anything that might've come across your problem. But have you ever thought about how to generalize that? There are exceptions, yes, but they are nasty cause they alter the program flow directly and don't store any information about other exceptions thrown before them. Personally, all my design are based on the assumption that there are not many errors preventing a function from doing what it was supposed to. It gives back what it was able to do, so that the problem has the possiblity to repeat it again with different settings or data. This increases autonomy of program parts and may guarant completely new and interesting problems while to continue developing. It motivates programmers (atleast me) to design code that is able to check, cope and live with errors, making the best out of it as well as atleast trying to archieve a part of the stuff you it is supposed to do in case of error. Back to the topic of storing errors itself, I noticed an advantage over classic procedural design: you can create a generic error-handling class that's implemented and documented once - not more, not less, you never have to care about it again. It would have all kinds of really nice functionalites like directly printing them, converting them to arrays, lists, program-readable code data as well as human-readable console text or so. It's one of the few think I'd deem OOP useful for: generalizing the stuff you have to do all the time, not to write getters, setters and other completely interfaces and inheritance trees. However, This is also why I think about not only continuing to write itk as a big set of C functions, but also in a rather custom, interface-based format using structs and function pointers to guarant such comfort for iterating errors. But no, that would create a mess of documentation, useless pointer structures and serious maintainability problems cause you'd have to also setup those function pointers... No, this isn't a good idea and I probably go better to leaving it to the classic approach of true/false return values. For more complex scenarios in e.g. complete frameworks or a game engine, I guess I'll simply stick to a structure for storing errors the user as well as the functions can manipulate. That ensures high performance on lower levels and comfort one higher ones. I'm again creeped by how few my fellow students do to prevent errors. It's all just "just get it done" and not "get it done but also do it well". Quickness is for sure always a vital point for development, but that doesn't mean it's a good idea to also sacrifice quality for even the smallest possibe speed advantage. Better try to grasp the big trade-off chunks before you start and think twice before you do it. Quality is still something I deem most important for software. Personally, I'd rather wait a few hours more, as a customer, to get a better product than a half-hearted speed developement. Look at PC games and operating systems. Most of the time you can't even try them out for a while cause they crash or dick otherwise. You paid hard money for it and it's not getting back until the dev's melon head can come around with a better solutions. Do you really want something like that? No. So better replace your urging manager with a better advertizer to whet the people's appetite in the beginning or even to motivate them paying BEFORE the software comes out. Preordering is a common thing today, to better stack some more months on top and get a bit more money to accelerate it.

No comments: