What Are You Working On? V13

[CarlBooth]

[QUOTE=Pery;24981476]I used [url=http://www.codeproject.com/KB/dialog/rtaGlassEffectLib.aspx]this[/url].
Actually I don't see any point of Microsoft pulling the glass effect, isn't Windows Vista/7 mean't to look a lot like that? Glass is visual sex IMHO.[/QUOTE]

If they hadn't hacked explorer to pieces in Vista I'd still use the Windows Classic theme.

[Skipcast]

[QUOTE=Pery;24977593]Some progress.
[img_thumb]http://img710.imageshack.us/img710/874/cloudcraft2.png[/img_thumb][img_thumb]http://img835.imageshack.us/img835/5228/cloudcraft1.png[/img_thumb]
Ideas welcome![/QUOTE]

Should be able to rename them instead of "World 1" etc.

Also, maybe show how big they are?

[Blade]

What the fuck, have been hunting this error down for ever.

(Java)

void Func()
{
	try
	{
		CorruptFunc();
	}
	catch (Exception e)
	{
		Log(e);
	}
}

try
{
	Func();
}
catch (Throwable t)
{
	Log(t);
}

It wasn't logging the exception for some reason. But when I changed the catch inside Func to Throwable it catches it. What? Does java not rethrow or something?

[Robber]

[QUOTE=high;24982571]What the fuck, have been hunting this error down for ever.

(Java)

void Func()
{
	try
	{
		CorruptFunc();
	}
	catch (Exception e)
	{
		Log(e);
	}
}

try
{
	Func();
}
catch (Throwable t)
{
	Log(t);
}

It wasn't logging the exception for some reason. But when I changed the catch inside Func to Throwable it catches it. What? Does java not rethrow or something?[/QUOTE]
You shouldn't ever get it in the second catch. When you catch it, it's caught. You can rethrow it though. [i]throw new Exception(oldException);[/i]

[Blade]

[QUOTE=Robber;24983972]You shouldn't ever get it in the second catch. When you catch it, it's caught. You can rethrow it though. [i]throw new Exception(oldException);[/i][/QUOTE]

It isn't being caught by the first though.

[nullsquared]

[QUOTE=high;24982571]What the fuck, have been hunting this error down for ever.

(Java)

void Func()
{
	try
	{
		CorruptFunc();
	}
	catch (Exception e)
	{
		Log(e);
	}
}

try
{
	Func();
}
catch (Throwable t)
{
	Log(t);
}

It wasn't logging the exception for some reason. But when I changed the catch inside Func to Throwable it catches it. What? Does java not rethrow or something?[/QUOTE]

Exception inherits from Throwable (don't ask why, it's Java), which means you must be throwing a Throwable that isn't an Exception.

[esalaka]

[QUOTE=nullsquared;24984153]Exception inherits from Throwable (don't ask why, it's Java), which means you must be throwing a Throwable that isn't an Exception.[/QUOTE]

Why would there [B]be[/B] anything throwable that isn't an exception? That makes no sense!

[ZeekyHBomb]

[QUOTE=Robber;24983972]You shouldn't ever get it in the second catch. When you catch it, it's caught. You can rethrow it though. [i]throw new Exception(oldException);[/i][/QUOTE]

Or just throw oldException;.

[editline]10:14PM[/editline]

[QUOTE=esalaka;24984246]Why would there [B]be[/B] anything throwable that isn't an exception? That makes no sense![/QUOTE]
throw 42; //:v:

[arienh4]

[QUOTE=esalaka;24984246]Why would there [B]be[/B] anything throwable that isn't an exception? That makes no sense![/QUOTE]
Welcome to Java.

To be honest, I uttered "That makes no sense!" at least every 10 minutes when I started working on Java for Android.

[Blade]

[QUOTE=nullsquared;24984153]Exception inherits from Throwable (don't ask why, it's Java), which means you must be throwing a Throwable that isn't an Exception.[/QUOTE]

Why didnt the throwable handler catch it then?

[ROBO_DONUT]

[QUOTE=arienh4;24984297]Welcome to Java.

To be honest, I uttered "That makes no sense!" at least every 10 minutes when I started working on Java for Android.[/QUOTE]
This.

[jA_cOp]

[QUOTE=esalaka;24984246]Why would there [B]be[/B] anything throwable that isn't an exception? That makes no sense![/QUOTE]

Both Exception and Error inherits from Throwable. Error is for situations that are not meant ever to be recoverable, while Exception is for everything else. It [I]does[/I] make sense if you had bothered researching it.

[gparent]

[QUOTE=jA_cOp;24986128]Both Exception and Error inherits from Throwable. Error is for situations that are not meant ever to be recoverable, while Exception is for everything else. It [I]does[/I] make sense if you had bothered researching it.[/QUOTE]
It's way easier to bury your head in the sand and just claim Java sucks every time any sort of little problem comes up.

[xAustechx]

[QUOTE=Jallen;24981150]Why would Microsoft want to put its hands in pies?[/QUOTE]

Oh Jallen you silly bastard. That was a metaphor.

[ROBO_DONUT]

Python's exception/error hierarchy makes slightly more sense, IMHO.
Everything subclasses BaseException, and error/exception don't really mean anything in particular. Exception is simply the more general case.

I don't think it makes sense to allow the subroutine throwing the error/exception to make a distinction between what should be recoverable and what should not. It should strictly be at the discretion of the function handling the exception/error, because the usage and importance is only visible at that level. Yes, it is up to you how to handle an Error/Exception, but the distinction creates inconsistency without any benefit.

[jA_cOp]

[QUOTE=ROBO_DONUT;24987110]Python's exception/error hierarchy makes slightly more sense, IMHO.
Everything subclasses BaseException, and error/exception don't really mean anything in particular. Exception is simply the more general case.

I don't think it makes sense to allow the subroutine throwing the error/exception to make a distinction between what should be recoverable and what should not. It should strictly be at the discretion of the function handling the exception/error, because the usage and importance is only visible at that level. Yes, it is up to you how to handle an Error/Exception, but the distinction creates inconsistency without any benefit.[/QUOTE]

It's not inconsistent, they mean two entirely different things. If you catch an object deriving from Error, you're not allowed to assume the program is in a valid state. And why should the handler decide? The thrower is the one who knows everything about what is going on. It's a good concept and it works in practice.

For example, Errors are perfect for contract-based programming. If a contract is broken, that's an error with your code that you need to sort out. Java's "assert" happens to throw an AssertionError, you can still catch it for logging, sandboxing and custom error displays and such.

Which gives you Throwable - you want to be able to treat Exceptions and Errors differently, because they are very different.

[ROBO_DONUT]

Honestly, if you call a minor subroutine and it goes "sorry I a whole gig and [i]broke the entire program[/i]", there's something seriously wrong. There shouldn't even be provisions in place for such a situation because it's so unacceptable.

[gparent]

[QUOTE=ROBO_DONUT;24987812]Honestly, if you call a minor subroutine and it goes "sorry I a whole gig and [I]broke the entire program[/I]", there's something seriously wrong. There shouldn't even be provisions in place for such a situation because it's so unacceptable.[/QUOTE]
The exact reason why you're not supposed to catch Throwable, right there.

[ROBO_DONUT]

Well it all makes sense now.
I can pretend Exceptions don't exist and let my program blow up in the rare case that they occur. Like how nobody checks whether malloc() is successful, because if it isn't then you've got some pretty serious problems anyway.

[gparent]

[QUOTE=ROBO_DONUT;24987969]Well it all makes sense now.
I can pretend Exceptions don't exist and let my program blow up in the rare case that they occur. Like how nobody checks whether malloc() is successful, because if it isn't then you've got some pretty serious problems anyway.[/QUOTE]
Exceptions are important, Errors, however, aren't meant to be treated by your program. They're only thrown for convenience if you wish to log.

[Chandler]

[QUOTE=ROBO_DONUT;24987110]Python's exception/error hierarchy makes slightly more sense, IMHO.
Everything subclasses BaseException, and error/exception don't really mean anything in particular. Exception is simply the more general case.

I don't think it makes sense to allow the subroutine throwing the error/exception to make a distinction between what should be recoverable and what should not. It should strictly be at the discretion of the function handling the exception/error, because the usage and importance is only visible at that level. Yes, it is up to you how to handle an Error/Exception, but the distinction creates inconsistency without any benefit.[/QUOTE]

Don't forget that Exceptions aren't just used for errors in python either. It's actually considered proper python to use exceptions for logic flow. For instance, all for loops look like this under the hood:

try:
    while True:
        item = data.next()
        # do stuff
except StopIteration: pass

This is in fact, how all iterables in python work.

[jA_cOp]

[QUOTE=ROBO_DONUT;24987969]Well it all makes sense now.
I can pretend Exceptions don't exist and let my program blow up in the rare case that they occur. Like how nobody checks whether malloc() is successful, because if it isn't then you've got some pretty serious problems anyway.[/QUOTE]

You can't really compare it to not checking the return value of malloc. If you're out of memory in a language with exceptions, an exception is thrown and the default behaviour for uncaught exceptions installed by the runtime (global exception handler) will take care of good, acceptable default behaviour. If you don't check what malloc yields, you'll end up with a segmentation fault/access violation at some later point in time.

edit:

And being out of memory does not mean an Error (as Java would put it) as it doesn't necessarily indicate a bug. For example, you could handle such an exception by freeing up a pool of memory you used for caching stuff somewhere else then trying again. (This might not be feasible in some Java VMs, but it's not uncommon in languages like C++)

[RyanDv3]

So far I don't really like either c# or java, feels like they insult my intelligence, make bad assumptions, and occasionally perform inexplicable magic.

Then again, I'm new to them, of course I'm going to feel uneasy going from one language to others.

[ROBO_DONUT]

[QUOTE=gparent;24988085]Exceptions are important, Errors, however, aren't meant to be treated by your program. They're only thrown for convenience if you wish to log.[/QUOTE]
s/Exceptions/Errors/
Total brainfart. All this talk about the difference between the two is making me :psyduck:
[QUOTE=Chandler;24988149]Don't forget that Exceptions aren't just used for errors in python either. It's actually considered proper python to use exceptions for logic flow.[/QUOTE]
Yep. I actually like this about Python.
[QUOTE=jA_cOp;24988158]You can't really compare it to not checking the return value of malloc. If you're out of memory in a language with exceptions, an exception is thrown and the default behaviour for uncaught exceptions installed by the runtime (global exception handler) will take care of good, acceptable default behaviour. If you don't check what malloc yields, you'll end up with a segmentation fault/access violation at some later point in time.[/QUOTE]
I honestly don't see the problem with a segmentation fault if your computer is probably out of memory, locked up, and swapping itself to death anyway.
Rearranging deck chairs on the Titanic, etc.
[QUOTE=jA_cOp;24988158]And being out of memory does not mean an Error (as Java would put it) as it doesn't necessarily indicate a bug. For example, you could handle such an exception by freeing up a pool of memory you used for caching stuff somewhere else then trying again. (This might not be feasible in some Java VMs, but it's not uncommon in languages like C++)[/QUOTE]
This is more of an exception to the rule. You don't always have a large cache you can free to make more memory.

[editline]11:32PM[/editline]

[QUOTE=RyanDv3;24988285]So far I don't really like either c# or java, feels like they insult my intelligence, make bad assumptions, and occasionally perform inexplicable magic.

Then again, I'm new to them, of course I'm going to feel uneasy going from one language to others.[/QUOTE]
Well I've already made an ass of myself, but I'm going to have to agree with this. Java really isn't my cup of tea.
There's too much for me to remember and think about. I'd prefer a language to just give me some tools and stay out of my way (like C) than try and enforce "safe" or "proper" coding practices and OOP structure.

[jA_cOp]

[QUOTE=ROBO_DONUT;24988376]I honestly don't see the problem with a segmentation fault if your computer is probably out of memory, locked up, and swapping itself to death anyway.
Rearranging deck chairs on the Titanic, etc.[/QUOTE]

A process being out of virtual memory is completely different from your computer being out of physical memory.

[QUOTE=ROBO_DONUT;24988376]This is more of an exception to the rule. You don't always have a large cache you can free to make more memory.[/QUOTE]

It doesn't matter. If you don't have anything special you want to do, you get the default runtime behaviour which is still better than a segmentation fault which can appear far from the place of allocation. There's a reason so many C programmers simply check for null, dump a description to stderr then exit.

[gparent]

[QUOTE=ROBO_DONUT;24988376]s/Exceptions/Errors/
Total brainfart. All this talk about the difference between the two is making me :psyduck:[/QUOTE]
Ahaha, and me and jA_c0p were really really scratching our heads about that one too on IRC. No problem man.

[ROBO_DONUT]

[QUOTE=jA_cOp;24988698]A process being out of virtual memory is completely different from your computer being out of physical memory.[/QUOTE]
Ok, but I'm not sure I understand the relevance.

[QUOTE=jA_cOp;24988698]It doesn't matter. If you don't have anything special you want to do, you get the default runtime behaviour which is still better than a segmentation fault [b]which can appear far from the place of allocation[/b]. There's a reason so many C programmers simply check for null, dump a description to stderr then exit.[/QUOTE]
This is a very good point and I can see how that would make debugging very difficult. I almost always assign values right after allocation, so if malloc() did return NULL, execution would stop right about there and I'd know exactly what went wrong. I think a simple assert(value!=NULL) will do in most cases.
But again, the point's kind of moot because a malloc() failure is a rare occurrence that usually indicates a more serious problem with the system, and, unless there's a cache you can free as in your example, there's really not a whole lot you can do about it.

[xAustechx]

-snip-
I'll show it tomorrow when I fix more things. Sorry.

[backwardspy]

[QUOTE=RyanDv3;24988285]So far I don't really like either c# or java, feels like they insult my intelligence, make bad assumptions, and occasionally perform inexplicable magic.[/QUOTE]
I'm just gonna go ahead and agree with this sentiment

[esalaka]

[QUOTE=gparent;24986255]It's way easier to bury your head in the sand and just claim Java sucks every time any sort of little problem comes up.[/QUOTE]

I never claimed Java sucks :saddowns:

[editline]01:53PM[/editline]

Stop disagreeing with Chris :frown: