Brilliant - but also horribly wrong

We probably all had that moment at least once during the first year(s): We came up with an idea, that was absolutely brilliant only to have it put down by others, who then showed us, how wrong it really was. And we learned a lot from it.

So what was the most brilliant, elegant idea you came up with in coding, which was also totally wrong?

Mine was, while I was working in my first job, fresh from university. I had about 6 months of professional coding in me and a really steep learning curve behind me.
We were working with C++ and within a framework created by my team lead, where we worked with plugins and sending/receiving an 'Entity', that has something in it, as inter-plugin-communication.

It bothered me, to write a lot of checks, to find out what I actually have gotten there. But since it was a plugin system, the base class had to stay universal.

My team lead was really cool. I loved bouncing ideas with him. And he was pretty open, even to the craziest of ideas. And in my naivety I was proposing to use the exception mechanism to 'catch' the entities and have implicit type information. And he let me just do it.

If I remember correctly (hey, it was 9 years ago) there was a main loop in the base class for the plugins, running on a separate thread, checking, whether there were new entities in a buffer.
If there were, it will start a new thread executing a HandleNewEntity () method, every plugin had to implement.

And in the plugin there was:

public virtual override HandleNewEntity()
{
  try
  {
    GetNewEntity(); //from base class, throws the new entity as exception
  }
  catch (EntityA_Type a)
  {
   //do something with Type A
  }
  catch (EntityB_Type b)
  {
   //do something with Type B
  }
  catch(...) 
  {
   // ignore, what you don't know
  }
}

I solved it... or so I thought. My other team members, saw it a bit differently.

'You cannot use an Exception! Exceptions are - hence the name - for exceptional cases. Something has happened, that is not supposed to.'
And then I learned about stack unwinding in C++ exception handling and the hidden mechanics, that made my approach horribly wrong.

I still like the idea, even after almost 10 years of experience and the knowledge, that it is just plainly wrong to misuse the exception mechanism like I did.

As a sidenote:
When I was recreating the whole thing, to learn C#, I was using a different approach. Register a Handler to a type and then have the handler executed, when that type comes by.

//Base class for Plugins, without multithreading overhead
private static Dictionary<Type,List<Action<IEntity>>> _typeHandlerDic = new ...
protected void Register<T>(Action<T> handler) where T : IEntity
{
   List<Action<IEntity>> handlers;
   if (_typeHandlerDic.TryGetValue(typeof(T), out handlers)
      handlers.Add(new Action<IEntity>(x => handler(x as T)));
   else
    _typeHandlerDic[typeof(T)] = new List<Action<IEntity>> { new Action<IEntity>(x => handler(x as T)) };
}

//in the main loop, after determining, there is a newEntity

List<Action<IEntity>> handlers;
...
if (_typeHandlerDic.TryGetValue(newEntity.GetType(), out handlers))
{
   handlers.ForEach(handler=> handler.BeginInvoke(newEntity,null,null)); //execute on separate thread
}