- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Real coffee man... sugar should stay afloat over the foam for a few seconds before going down. Of course, sugar is for the weak.
Our coffee machine is broken... must have caffeine...
Admin
>I'm a bit tired of you IT snobs ranking on Access developers. Some of us code carefully, use best >practices, and produce well running applications that work well for the users.
Yes, and I'm a bit tired of people saying VB developers suck too! By now, it really ought to be assumed and thus has no need to be said.
The reason these feelings still exist is because we're rather certain that if the Access and VB developers knew better, they would use different tools. The fact that anyone deigns to still use Access or VB is very telling: they either don't know any better or they're getting paid an enourmous amount to stoop so low.
Admin
Hell yes. If you can't think of what to do with an exception besides catching it, YOU SHOULDN'T BE CATCHING IT AT ALL. Leave it up to a caller to decide.
P.S.: Logging an exception does NOT count as "doing something meaningful" with it.
Admin
There is a limitation in Java class files, of no more than 65536 bytes of compiled Javur bytecodes inside one method of a class. Compiled. Has nothing to do with try-catch blocks, though their use obviously adds to the method length. Long string constants, to contrast, do not since they are stuck in a distinct constant pool. Likewise for 8-byte integer literals, inner classes (they go in a very bad, dark place in Java) and so forth.
For comparison, we have this ass-horrible method at work. It's in a likewise ass-horrible Swing Panel subclass which encapsulates most of our homegrown CRM stuff. It grabs fields from the panel's constituent widgets and shoves them into the database in one orgastic transaction. Its length used to be measured in hundreds, but is now measured in the thousands of lines. I'm not talking about those "}\n" lines either. Yet it runs nowhere close to the 64KiB limitation; its compiled form was somewhere around twelve kilobytes the last I took a look (just to see how close we were).
I guess the OP had misunderstood what he'd been taught at Potato Compootard Collage. Not that I blame him.
Admin
Writing the entire thing in an entire JSP would be a real WTF. This looks like it is a JSP page with a very large servlet behind it. Im guessing all the fancy frameworks weren't there or not relatively well known back then. Even better would have been to not use JSP and just use a single method to serve web pages.
Admin
Admin
When I started learning perl (~7 years ago) I had worse scenario ... I had to update/edit/fix bugs on a classified site someone else have written and it was single ~110kB (yes , right!!) CGI-script...
Full of if-elseif's and print's.The record was single if-elsif-elsif.... around ~25 terminal pages long ;)
Admin
What a DORK too bad so sad I see it all the time...people either look good or are good at what they do and clearly this guy looked good...
Admin
uh, you mispelled "user" as "users".
just kidding. i developed my first app on vb6 and access. it was the door that let me into db programming and, no, i didn't let it hit me on the way out. ;-)
access does suck, though. or it did.
how about using an access front on end on a real client server db like postgresql?
then, when you lose the access front end, you can rank on "access guys," too.
just kidding. seriously, i think you can differentiate yourself from other "access guys" by going the postgresql route and provide a better product to your customers.
you would have to learna bit about a new db, but you have the talent so why not?
Admin
That depends, as well. If your caller should not have specific knowledge of your implementation, then you may want to wrap or substitute your Exception in some way. You should not implement your DAO classes to throw SQLExceptions, since yor DAO may encapsulate access to non-SQL data sources. Does a SQLException make sense if I your backend is actually a webservice?