M
Matt Baker
Guest
I had a rant...and then deleted it after I read the article, so I'll start again. I've been working with java as a simpleton since 1997. C# a bit less. Thanks for the links to how RUST handles this, is good to read how someone uses a few language constructs to enforce handling of no nulls. After years of reading garbage code and dealing with garbage exception handling in everyone's code, especially mine, I wrote a wiki with do's and don'ts here on exception handling based on what I've learned working on OEM which is all java and I make all my team members read it. I've encountered lots of really badly written exception handling code for languages that make use of try...catch...finally concepts, and a basic set of rules makes life easier. The same set of rules applies to C# code and ABL code. In contrast my experience with functional programming is extremely limited. I've read the articles on rust that was posted and I've tried to read a little bit of go. I haven't studied either of these languages. Java, javascript, and C# are my languages of choice and experience so anything I have to say about purely functional languages is worthless. Functional programming is hard. I think I can safely say most developers come from the procedural or OO background. From a learning perspective it is always good to read other code and understand the concepts and the experiments in language syntax. You can then bend the concepts to your own work. I think purely functional languages are fun...for a few minutes. Then I realize the language bends my mind so I can't figure out how to get anything done. Makes me wonder if the limited sets of libraries for some of these is directly caused by the lack of usability. I can't say that the choice of exception handling in java and C# has improved the world, but it is an easily understandable language concept and works for more than the 5 of the top 6 most popular languages on earth. The way RUST enforces no-nulls and the resulting return value handling is neat. I do kind of like it. It isn't hard to understand or implement, while also forcing the developer to think about every case the compiler knows about. The "error or value" baked into the language effectively uses an enumerated generic (I'm making this term up) and a not-null requirement combined with an enforcement of all cases in the enumerated type have to be handled. You can emulate some of this in java or C# with a "holder" object and generics in OO languages and annotations. Java has @NotNull for parameter declarations. C# has very similar syntax. If you use them, the compiler will enforce them, the rest is just "don't throw an exception", rather use the holder object. I think RUST solved it in a fairly clean way as it doesn't allow you to miss an exception case. At the end of the day if you pick SEH or enumerated return objects a few things go a loooong way, and I don't care what language constructs are enforced. There are some class of things that defy the best language design. A few below: 1. The best exception handling is garbage if it doesn't do the right thing when one is encountered. Your program may not crash, but you don't want an exception message box with "failed successfully" and no way to clear the error message. No amount of language enforcement is going to prevent your program from doing stupid things if you don't know what you are trying to accomplish. I've seen code (again and again) that does things like 'if a socket connection completely failed due to a bad hostname, the error message returned to the user would read "invalid username or password"'. 2. Your program needs to return good error messages when there is no good thing left to do other than crash. "save failed" type messages are useless. 3. In most languages null pointer exceptions are a real thing. Except that fact unless you can use RUST or something similar. No all of use can use a language that doesn't have them. Use a linting tool in both your IDE and your build pipeline goes along way towards fixing our human short comings. A few years ago when we introduced SonarQube to our build process.... my team had to fix 1600 potential null pointers in one project code base. This was after years of manually looking for them and fixing them. Thought we were doing to good.... 
4. All code is code reviewed (assuming you're not in your grandmother's basement by yourself...even then you can still ask) by more than one set of eyes . We all do stupid things. 5. Don't lose information when handling an error. I've seen uncountable times when the real source of a problem is thrown away for a different error message. don't do this. preserve everything you can about the error until you are absolutely sure your program can recover or log the problem. 6. Even unit tests are written incorrectly. Those get reviewed and linted and tested. Turtles all the way down.
Continue reading...
4. All code is code reviewed (assuming you're not in your grandmother's basement by yourself...even then you can still ask) by more than one set of eyes . We all do stupid things. 5. Don't lose information when handling an error. I've seen uncountable times when the real source of a problem is thrown away for a different error message. don't do this. preserve everything you can about the error until you are absolutely sure your program can recover or log the problem. 6. Even unit tests are written incorrectly. Those get reviewed and linted and tested. Turtles all the way down.Continue reading...