|
WTE does ObjectHolder do? That I can see no value to.
The userBase model is common. You use an execution container to encapsulate permissions etc. The use of an anonymous class is, however, poor work.
Why aren't the methods synchronized, instead of filling the method with a synchronise block? Damned weird, but there may be a reason.
Reality is an illusion caused by a lack of alcohol
"Nagy, you have won the internets." - Keith Barrow
|
|
|
|
|
I guess ObjectHolder is to make the variable assignable from inside the anonymous code as that can only use final variables.
|
|
|
|
|
Yes, i thought that's what it was for.
However, I was more puzzled by:
- The double synchronization of the AtomicBoolean. It is synchronized in the method itself (waiting for it to become true) AND in the listener. Since the method returns, something is smelly.
- The throwing of 2 exceptions (one in the listener and the other in the method)
|
|
|
|
|
I wanted to mention that, the point of an AtomicBoolean is that it doesn't need synchronisation because it's, well, atomic. 
Reality is an illusion caused by a lack of alcohol
"Nagy, you have won the internets." - Keith Barrow
|
|
|
|
|
Nagy Vilmos wrote: I wanted to mention that, the point of an AtomicBoolean is that it doesn't need synchronisation because it's, well, atomic.
The synchronization isn't necessarily for the setting/getting, but for the wait()/notifyAll(). They are using the variable both as a flag and a synchronization object, though it is a little unusual to wait with a relatively short timeout and then loop if you are going to signal the monitor as well.
I personally would have used CountDownLatch or CyclicBarrier.
|
|
|
|
|
brisingr_aerowing@Gryphon-PC $ rake in_the_dough
Raking in the dough
brisingr_aerowing@Gryphon-PC $ make lots_of_money
Making lots_of_money
|
|
|
|
|
WTE the coder has done? AtomicBoolean is already atomic and doesn't need a syncd block
Beauty cannot be defined by abscissas and ordinates; neither are circles and ellipses created by their geometrical formulas.
Source
|
|
|
|
|
Believe it or not, this reminds me of one UI programmed in Java that I saw about a year ago. It was demo of a software meant for lawyers. Somewhere in UI, there was was a search window and the user was expected to enter the Primary Key (a 10 digit number), the name of person and part of his phone number.
|
|
|
|
|
Maybe they could not figure out how to make a generic, synchronous handler that returned a User object?
This might as well be synchronous since it will block forever anyway. Are there any other threads involved here? Maybe some sort of Action pool? Maybe a similar model is used for full asynch?
If it is single threaded, it is equivalent to
User ret = userBase.invokeAction<User>(email,
new GetUserByIDAction(),
new GetUserByIDActionExecutionDetails(id));
if (ret == null)
throw new UserNotFoundException(id);
They had to use synchronized due to wait/notify.
|
|
|
|
|
I'm in the middle of writing an app that imports a ton of data from an old version of an application (written by commitee!) with about a dozen tables in it to a database of more than 80 tables. Of course, because of the horrendous nature of the existing data (and we NEED it!), it has to be edited, parsed, interpreted, scrubbed, validated, normalized, blah, blah, blah, and takes many passes to go through and build the new database. So, I'll wrap my automated scrubbers and importers in Tasks, to keep my UI alive and show me what's its doing along the way, right? Right!
Well, when you do that, the Tasks can "bloat" your stack trace when something goes horribly wrong. How bloated you ask? Well, the code can throw a stack trace of about 20-23 lines long. But, put that same code inside of a Task and blow it up the exact same way and the stack trace jumps to a mind blowing 163 lines, with inner exceptions going six levels deep! WTE!!
|
|
|
|
|
Have you considered writing robust code? 
Reality is an illusion caused by a lack of alcohol
"Nagy, you have won the internets." - Keith Barrow
|
|
|
|
|
There are always speed bumps on the road to robustness. 
|
|
|
|
|
You're simply not trying hard enough. Put each iteration of the loop in a giant try-catch and quick as a Hollywood marriage all your problems are sorted. You could even go the extra mile and log the exceptions.
Reality is an illusion caused by a lack of alcohol
"Nagy, you have won the internets." - Keith Barrow
|
|
|
|
|
Yeah, right! Too bad I need to fix all the problems with the data, otherwise I would ignore 'em and log 'em. The script the app runs already generates about 120MB worth of log data just showing what it sees in the data and what it does to it.
|
|
|
|
|
Has anyone else come across the bug in Visual Studios 2012 where it runs code that isn't there?
I created an application and then I decided against some of the features I had in the application. So, I removed them. Buttons and grids etc. were removed, but alas, Visual Studio 2012 is so epic, it still ran all the missing code and displayed everything I removed.
I went further into this and decided to start from scratch, deleted the entire application and started a new one with the same name. It obviously didn't delete the previous project code completely, and had it stored somewhere, after it had deleted the actual project, so when I finished creating the new application, it ran like the old one. FML. So I removed EVERYTHING, all code, and the entire GUI and it still ran. WTF? I eventually copied the code, pasted it in notepad, and started in a blank app instead of Windows forms. Pasted the code back and added everything else manually.
|
|
|
|
|
Save the changes in the files, Rebuild the project and run it
|
|
|
|
|
Could it be that you had build errors and selected the option to automatically run the last successful build?
|
|
|
|
|
|
But why would it still be there after recreating the project as empty?
|
|
|
|
|
An empty project is obviously an error.... 
|
|
|
|
|
For some reason or another, it obviously didn't build it again before running. I'm guessing you either disabled the auto-build or (as mentioned above) you had a build error and had it set to always launch the last working build in that situation.
Sounds like PEBKAC to me 
|
|
|
|
|
On occasion, a build doesn't go quite right for some reason and the final .EXE isn't updated. I haven't seen that problem since the VS2005 days.
The solution to the problem is easy: Build menu -> Clean Solution then Build your solution again and run it.
|
|
|
|
|
Had to do the old "clean solution" a lot back in the old days...
|
|
|
|
|
I've only seen that when C# is involved. It makes copies of all the using DLLs. So if DLLs use DLLs, and there are 100 projects in the solution, you could end up with 100 copies of the same DLL. The problem then is if you change one of the DLLs. It sometimes doesn't get re-copied and the whole build falls over in a heap. I've got scripts just going round deleting all copies the DLL I am rebuilding.
|
|
|
|
|
All I've ever done is make the external .DLL's part of the project and mark them "Copy Always". If there was a problem, Clean always worked. I never had to build a special script to do any of this for me.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
