[Grug]

All hail Java!

I do say I compliment you aldo on your tidy and well kept code. Some people I've seen, *shudders*, have stuff all over the place with little to no comments.

I'll probably take a look at php, it seems fairly simple to use... is it?

HLP should have a code Academey...

[kasperl]

Can you do me a favour, and use the EINDE: DNS (minus the space, smiley prevention) as a start echo?

The existing program is already sent away, stupid as I am, and there are some existing logs already...

[aldo_14]

I'll work something out, then.

[Sandwich]

Originally posted by Grug
I'll probably take a look at php, it seems fairly simple to use... is it?

Yes, if you want to learn it up to a basic-medium level. Beyond that and you start delving into areas that are both quite powerful and quite confusing for someone with my brain structure.

[Grug]

Originally posted by Sandwich


Yes, if you want to learn it up to a basic-medium level. Beyond that and you start delving into areas that are both quite powerful and quite confusing for someone with my brain structure.

Hehe. That an offer to help when I get stuck?

[Sandwich]

No, that's a request for help when you surpass me.

[Grug]

lol. Doubt that'll happen any time soon.

I'll trade my (amatuer) Java knowledge for (expert) php knowledge.

[aldo_14]

Originally posted by aldo_14
I'll work something out, then.

Um... I'm really busy with work ATM - this is the last week of my job, I need to document stuff for whoever follows me developing the...thing.. - not sure when I'll be able to fix it.

[Grug]

That would also explain your absence in the internals?

[ZylonBane]

Ahhh, nothing quite like a screenful of Java code to test the ol' gag reflex. What a horrid, bloatful language. "System.out.println" indeed. Blech. Ack. Blargh.

[Grey Wolf]

The sad thing is it actually looks quite a bit neater than the C++ code I just wrote the other day in my Computer Science class.  330 lines or so just for Tic Tac Toe and some basic AI.  Far too many nested tables...

[aldo_14]

Originally posted by Grug
That would also explain your absence in the internals?

Pretty much, yes.

Originally posted by ZylonBane
Ahhh, nothing quite like a screenful of Java code to test the ol' gag reflex. What a horrid, bloatful language. "System.out.println" indeed. Blech. Ack. Blargh.

Thank you for your oh-so-valuable and helpful contribution.

[WMCoolmon]

Originally posted by aldo_14
No, it's a quick and dirty hack with exceptions........there are far better ways to do this sort of thing with recursion or tree-building or regular expressions, or really anything beyond a strict-format linear run.  But they take longer

You should take a look at the code for my ships.tbl reader I made awhile back. Something I would call 'hackish' would not enforce format in any way, would just read the lines in and parse them. And it wouldn't have any globally defined constants; they'd all be tacked into the code.

I don't even know how to use exceptions in C++ I just (try to) keep them from happening (eg: Do not use a null pointer).

Although the whole exceptions thing strikes me as not having a place in a well-coded app, because generally you do want to keep that array from overflowing, or keep that null pointer from being used. Exceptions are (IMHO) like failing to avoid a fallen tree in the middle of the road because you have insurance.

[aldo_14]

Originally posted by WMCoolmon


You should take a look at the code for my ships.tbl reader I made awhile back. Something I would call 'hackish' would not enforce format in any way, would just read the lines in and parse them. And it wouldn't have any globally defined constants; they'd all be tacked into the code.

I don't even know how to use exceptions in C++ I just (try to) keep them from happening (eg: Do not use a null pointer).

Although the whole exceptions thing strikes me as not having a place in a well-coded app, because generally you do want to keep that array from overflowing, or keep that null pointer from being used. Exceptions are (IMHO) like failing to avoid a fallen tree in the middle of the road because you have insurance.

I use exceptions as a sort of cascading fallback-on-error control; easiest way AFAIK to simply halt a program on error (although there's not really a recovery strategy that can be used here; just carry on and print out what result there is up to the failpoint)...

basically, if there's an error which can't be handled at the local 'level' (i.e. in the called routine), I can use an exception to inform the callee and let it either perform recovery/reaction, or simply pass that exception on the next callee layer, etc, until something that handles the exception receives it;  what you're talking about is error avoidance, but exceptions are really for error detection and recovery anyways, which is a bit of an alternate paradigm - i.e. prevent the errors happening, but where there is the possibility of error, handle and recover (or fail gracefully) from it.

For example.... I'm working  (well, was working) on a distributed application that, in simple terms, requires nodes to communicate with each other via specially formatted string messages.  The nature of it is that each node sends messages to each other, and that each node is responsible for formatting the message prior to sending.  

On receipt, the receiver uses a method to extract the information it needs; there's the possibility due to code error on the other node (perhaps a version difference, or a 3rd party coder - it's a general infrastructure being developed rather than a single app, or simply corruption) that the string message format is dodgy.

If so, I can simply throw an appropriate exception from the method that obtains info from the string, that will inform the receiver node (callee) of the formatting error; I can't handle the error itself within the method, because the callee needs to know there is a format problem which is by nature unrecoverable.  I also need to skip everything affected by it, hence the use of a try/catch block...  point being, in this case I can't guarantee there is no error, because the data - the error source - comes from a 3rd party source and cannot be natively guaranteed as correct.

EDIT; not that I actually do error correction (actually, it's a concept prototype; the deliberate intent is to fail-on-error at present.  Not my intent, though......)

That's an example for proper use of exceptions, IMO

[WMCoolmon]

Wouldn't roughly the same thing be possible by returning the function with a special value to indicate failure/the error?

[aldo_14]

Yeah, but then you'd be adding in specific handlers for each possible error return case as well as the allowed return; you'd also need to add in constants to check for for different error causes (i.e. instead of using an AttributeChangeException, InvalidChangeException or similar).

You'd also have to add in explicit backtracking to find the error cause and fetch the variable/s that cause it; using an exception (specifically designed subclass), you can encode the problematic data or any other info encapsulated within the error case.

Not to mention that you'd need to define a returned special value which cannot be generated by legal data - which in turn implies you need to make assumptions on what paramater values and return you can get.  And there's a side issue of typed returns; how do you define the error Object for a method returning type ArrayObject (or something)?  

(there's also possibly a memory issue if returning inherently large objects for the return, or perhaps if you are relying on multiple returns to determine an action... but I'm not sure of the comparative memory usage of an exception, however)

So... at a certain, simple level IMO you could use a special type return but you'd not have any real advantages I can think of over an exception; and at a higher level you'd lose the advantages of encapsulating the error type, data and cause in an exception object.

Bearing in mind this is from a Java and not C/C++ perspective of exceptions

[WMCoolmon]

Ahh, I see. I suppose in C you could use an error struct and a goto to do something like that, and in C++, right off the top of my head, you could create an error object class with an identifier int, then derive types from it, allocate the type, return a pointer to it and cast the pointer type in the caller function. Messy, but it'd be about as fast as you could get, aside from having things pre-allocated.

Whether or not that'd be faster than exceptions or not I don't know. It'd basically be the same thing, except not using any (hidden) global variables to pass the errors along.

Actually, I guess you could make an 'error' struct, then have a union (basically a multi-type object, with enough space to hold the largest object) with pointers to all the various error structs. You wouldn't have to cast pointers then, and it'd be valid in C/C++, and could still have the flexibility of the class method.

All of that, though, I doubt you could do in Java. To quote the one and only Java book I've read - "Java is a strongly-typed language".

[karajorma]

The other benifit of Java's Error handling system is that it forces you to think of possible errors that could easily be overlooked in C or C++

For instance any file access operation in Java forces you to handle the FileNotFoundException. How many C++ programs crash out simply because the programmer forgot to think of the possibility that the file might not be there when it was needed?

If you're writing a program and see an exception that can't picture a cause for it's often a big neon sign warning you that you've forgotten something.

[aldo_14]

Originally posted by WMCoolmon
Ahh, I see. I suppose in C you could use an error struct and a goto to do something like that, and in C++, right off the top of my head, you could create an error object class with an identifier int, then derive types from it, allocate the type, return a pointer to it and cast the pointer type in the caller function. Messy, but it'd be about as fast as you could get, aside from having things pre-allocated.

Whether or not that'd be faster than exceptions or not I don't know. It'd basically be the same thing, except not using any (hidden) global variables to pass the errors along.

Actually, I guess you could make an 'error' struct, then have a union (basically a multi-type object, with enough space to hold the largest object) with pointers to all the various error structs. You wouldn't have to cast pointers then, and it'd be valid in C/C++, and could still have the flexibility of the class method.

All of that, though, I doubt you could do in Java. To quote the one and only Java book I've read - "Java is a strongly-typed language".

Offhand, that sounds (semantically) pretty similar to the existing Java setup... if I understand you right, you're suggesting some form of generic structure which contains links to structures for specific error types? (struct is methodless, isn't it?... been ages since I did C); i.e. relating to the specification/identification of the error type?

Java equivalent is loosely the inheritance hierarchy of the exception class; i.e. there's the generic Exception class, and subclasses (whose identity conveys a specific type or group of error/s) of that such as ArrayOOB, ClassCast, etc.  The try/catch black handles that ala

Code: [Select]


try {
//blah
}
catch(ArrayOOBException aooe)  {
//OOB specific stuff
}
catch(ClassCastException cce){
//cce stuff
}
catch(Exception e) {
//generic exception handling for any type not caught in above catch
}
finally {
//clause which occurs in exception or non-exception case (always)
//i.e. to cleanup on end*
}


From what I suggest, you're suggesting something very similar in effect, but not organisation.

As an aside, this seems interesting.  The stack trace for java exceptions is quite slow, for one thing, if exceptions are not used carefully.

*NB: I don't use finally much, myself, I usually forget ... apparently in Java 1.1 there's a potential error if you have a try {} finally{} block, where exceotions can be lost...not sure if that still applies to newer java versions.  C++ - AFAIK - doesn't have an equivalent to finally because of the more explicit memory allocation/deallocation

EDIT; I should point out I only used the generic Exception supertype in the previous (parsing thing) code because I didn't feel the need to define a specific new type.... argueably could have defined something like a FormatException class.

[kasperl]

OK, I think this thread is teaching me a lot more then I ever dreamed off, thanks, all of you.

The program at hand as been used, and used reasonably well, and the problem has been fixed. I think, a bit. I'm going to write a batch file to clean out the winXP Hosts file, and all should be reasonably well, as long as she uses Mozilla.


I'll be using the code in this thread to write any parser I think I  might be needing, if I need to do something quick. I think I can handle quick copy/paste/rip hacking.