RomRaider

I wanted to comment on the way code uses exceptions for everything, I believe this is a less then perfect approach.
Let's take an example:


Empty catch block? That's an alarm. This makes debugging and understanding the code pretty difficult. Since there are potentially multiple places where exception would be thrown, maybe somewhere intentionally and maybe somewhere unintentionally, how would a person developing know the original intent?

Here is an even worse example:


Again - empty catch block. Around multiple methods, each of them also ignoring the exception already. What's the purposes of this catch here? This is confusing and only hides issues. I do not know what was the reason for this approach - maybe someone was in a rush to write the code faster, but I believe this should be improved.

If whoever with push privileges would be interested, I can make some changes in this department - actually I have already made some: https://github.com/RomRaider/RomRaider/pull/55

Effective Java™ by Joshua Bloch


ObjectCloner.deepCopy would be a perfect case where this principle should be followed.

What do we currently have?

But what exceptions could be thrown by the block? IOException and ClassNotFoundException. We are not expecting these to happen here under normal condition, these would indicate that something fatal is happening and there is no chance to recover from that fatal issue. Thus a better implementation of this method should be


In this improved version we take care of the exceptions right here and not spill the job of taking care of this exception outside of the method.

Something along the lines of https://github.com/RomRaider/RomRaider/pull/69/ - will be happy to fix more of these

Hey,

Yeah, I certainly agree with you that this is just poor programming practice in any language that includes an exception handling feature. Unfortunately many folks have worked on the code over the years so probably the history is gone for this sort of thing.

Dan

Hey Danny, FWIW, when I converted the two old and even older SVN repos to Git to help the project into the future, I preserved ALL of the commit history that was available, only inserting a small delta in between during the Git Graft operation needed to join the two disconnected histories. So a git history on the file and/or layered recursive "git blame" (each execution provides an origin commit, which you can then repeat the operation on the parent of) on the lines in question should at least bring up their comments (if any) and the context of the change to aid understanding of intent.

I've not taken a look at this project since Mr PC nuked some of my posts, just logged in today as I receive various "can't get on the forum" messages via FB, however I might have to grab a copy and see how it is these days. Maybe a little more cross platform? Likely still on ant, though, I guess. I tried to get it converted to Maven but some of the dependencies were in the hard basket and needed some code changes to make work, IIRC. Likely still have the branch and notes somewhere, though if there's interest.

I would be interested in that branch if you still have it. I've spent the past two days or so looking through this codebase and I would really like to bring it "back to life". From my basic understand as of now, the two main hurdles for updating it are: 1. The native dependencies which have been built for 32bit platforms and 2. Drivers for J2534 interfaces only being 32bit compliant. While I've dug deeper into what fixing the first issue would look like, and have noticed that someone got a 64bit "alpha" driver working for J2534, I still don't have a clear picture of everything that would need to be modified.

From my perspective, getting this to run on the current JVM is pretty important as having a more accessible development environment will, hopefully, attract more contributes. I would say continuing your work to migrate this to maven soon follows that in importance, however if it's nearly complete it's worth just getting out of the way. Also, just to note, I understand this was a topic for discussion before but given that the posts were relatively old (I believe 2013 was when most of the activity ended) I was hoping that the state of some of these dependencies has evolved enough for us to move forward with a bit less headache (may very well not be the case lol).

I guess a more realistic question to ask before going any further would be does RomRaider even need to be updated? While updating code is great, "if it ain't broke don't fix it" may apply here. The only real case I can make for even attempting this at this point would be if there were enough developers interested in contributing who are currently put-off by the dated codebase. A more bias second reason for myself is that I really wanted to use this for my own car and, as a developer by trade, having a robust codebase for the program that could detonate my engine is appealing ^.^

Disclaimer: I understand the tune controls whether or not my engine has issues, but this is a program that controls how the ROM is written to be used with ECUFlash so I still feel it's pretty relevant.

Would love to get some input from you as I've seen you around the forums quite a bit

I'm personally heavily biased against Java... if a port to a Python environment using Wx for GUI was in the works, I'd likely be interested in developing

As you said though, I don't see RomRaider really needing any huge updates. Personally, I never use RomRaider myself for ROM editing. I use RR Logger if I'm laptop logging (though mostly use my tablet and BtSsm for the Legacy) or ECUFlash to modify a ROM.