.NET (Core and Framework)

public static IEnumerable<IEnumerable<T>> Split<T>(this IEnumerable<T> source, Func<T,double> predicate)
		{
			//throw an error if the source is null
			if (source == null)
			{
				throw new ArgumentNullException("source");
			}
			
			var remainingSequence = source;
			while (remainingSequence.Count() > 0)
			{
				var currentElement = predicate.Invoke(remainingSequence.FirstOrDefault());
				yield return remainingSequence.TakeWhile(t => predicate.Invoke(t).Equals(currentElement));
				remainingSequence = remainingSequence.SkipWhile(t => predicate.Invoke(t).Equals(currentElement));
			}
		}

valueList.Split(x => x.Name)

Pascal Ganaye wrote:

I am losing faith in the ClickOnce ability to make the install easy and fail-safe.

Dave Kreskowiak wrote:

Think about it, if you really were out of memory, how would there be enough memory to create an instance of the OutOfMemory exception object??

Dave Kreskowiak wrote:

Besides, how are you going to know what you did wrong to generate the exception??

Bastard Programmer from Hell

Eddy Vluggen wrote:

I'd expect a decent OS to reserve some memory and to give that specific warning
before all memory is consumed, otherwise there would never be such a
message (due to string-allocation).

Eddy Vluggen wrote:

We don't, but we handle the exception like any other; there's multiple ways a
write can fail, yet it's hard to have the application "know" what it did wrong.

Dave Kreskowiak wrote:

It could be a genuine running low on memory case, but if his code is generating this exception and he doesn't know why, he's got much bigger issues that blindly trying to free up resources in his own code.

Bastard Programmer from Hell

Eddy Vluggen wrote:

That'd be my course of action in this particular case; the user might terminate
some other app, like World of Warcraft, to free up valuable system-resources.

Eddy Vluggen wrote:

I'd guess we both would display a message and write a note in the eventlog, as
that's almost a default for the unhandled exceptions-handler

jschell wrote:

Excluding a poorly configured (and non-default configured) windows OS a Net application will NOT run out of memory because of some other normal application.

jschell wrote:

However many exceptions handled like that allow the user/app to continue.

 

<layer>An Out of Memory exception probably isn't something that should allow the app to continue. It certainly shouldn't be allowed to continue unless one considers carefully many possible error scenarios.

Bastard Programmer from Hell

Eddy Vluggen wrote:

I wouldn't expect it on a modern machine, <layer>but it can happen when your system is low on harddisk-space, since there's no place to grow the swapfile. Usually the system begins to crash when you're in that place

jschell wrote:

An Out of Memory exception probably isn't something that should allow the app to continue

Luc Pattyn wrote:

Most Exceptions exist to tell you something is going wrong, however also to give you a chance to act upon the situation.

Luc Pattyn wrote:

And if my app holds several algorithms to do something, and the preferred one fails with an OutOfMemory, it can still continue with the probably slower but less memory-hungry alternatives.

Luc Pattyn wrote:

What I'm saying is an exception is only bad if you can't cope with it;

Mehdi Gholam wrote:

What is the best way to handle

Pascal Ganaye wrote:

What is today's market share of Windows various flavour at home?

Pascal Ganaye wrote:

Do people still use Windows Me?

Pascal Ganaye wrote:

Do they have Windows XP with no service pack?

Pascal Ganaye wrote:

.NET framework 4 client requires Windows XP SP2, am I going to alienate my
prospective client if I requires that too?

Bastard Programmer from Hell

Pascal Ganaye wrote:

.NET framework 4 client requires Windows XP SP2, am I going to alienate my prospective client if I requires that too?

shingouki2002 wrote:

at least in the realm of visual appearance