@hocho not quite, a custom exception would always be visible as CustomException when you log it because it calls ex.ToString() so you'll always have to look for the enum property to know what went wrong. What I want is to have the reason for the exception where it belongs which is the name of the exception like SettingNullException rather than CustomException.Error = "SettingNull".

@hocho manipulating the string seems like a really bad idea ;-] if you however meant creating the string from scratch, it would be even worse.

I read this a few times and still don't understand whether there's a way to catch a dynamic exception solely based on it's real type rather than string type name. I.e. catch (SettingNotFoundException snfe) is simply impossible. Will pushing the consumers to stringly typed programming be something what they hate you for?

In my very personal opinion, I find dynamism rarely helpful in compiled languages/environments including C#/.NET. I think I understand what you're trying to achieve in terms of readability, code tersity, and avoiding type proliferation. I'm just not seeing how using this "heavy artillery" is an adequate way even if that complexity is isolated in a single class. Since it's working as stringly-based, why not just use a naive implementation of a DynamicException which would have some kind of read-only property (string ExceptionKind)?

@IgorSoloydenko no, there is no way of catching such an exception by it's type because it's not known at compile time. The type is generated a runtime and isn't actually ment for catching. 99.99% of failures mean a dead end anyway. It rarely makes sense to catch anything. Using exception filters is the only way to catch my dynamic-exception. My dynamic exception should just make it easier to create an exception with a helpful name and a message with additional information because it's what most exceptions are all about. I find it's unnecessary to create a new class for each case.

@IgorSoloydenko a property is virtualy a no-go because rarely any logger dumps properties and even Exception.ToString doesn't do it so usually all you've got is the name of the exception and a message. It's up to you to put as much as possible there that can save you later ;-) I don't see any use in creating a full-blown class for just two strings that I'll never use anywhere else.

I do not propose creating an exception type per a possible application hiccup. I'm saying a "regular" generalized exception may work better. Or, in other words, I don't see much benefit in this (rather complex) dynamic solution. The ToString() can always be overriden to incorporate this ExceptionKind field if necessary. Sorry, I didn't mean to say the code is bad, or anything. I just truly don't feel there's a necessity nor any benefits. The way the DynamicException is created can be replicated for a single static exception type. Creation from a tuple may indeed be pretty nice.

@IgorSoloydenko I do not propose create an exception type per a possible application hiccup. and yet this is exactly how it should be done. There shoud be a dedicated exception for each failure type. Only then you can find a bug more quickly. I've seen enough exceptions with a message like Error in settings and the exception type what just Exception. Great, very helpful but I already know that becasue settings don't load :-) The name of the exception and the message are the two most valueable things when something goes wrong. That's why I want to be able create them easily ad-hoc.

I simply think that the proposed DynamicException is not much different from a general "CatchEmAllException" with string used to differentiate the kind

the catching machanism and filtering is mainly ment for unit testing, I don't plan to catch anything but an Exception at runtime, perhaps sometimes a OperationCencelledException but that's it

The fact that it will compile into a different exceptions at run time, is not making a big difference. because the actual type is still originating from a string/ErrorCode

you're right, it's just that, and this is exactly what I want :-) when you get an email or a user tells you what went wrong all you'll get is SomethingWentWrongException: You need to check this and that to fix it.

how is throw new ("SomeKindaSpecificExceptionType", "Some payload").AsDynamicException() is better than throw new MyGenericException("SomeKindaSpecificExceptionType", "Some payload")? this i still can not comprehend

the amount of information relayed is the same in both cases. am i wrong? (both type/metadata and payload)

In order to be able to track down a bug you need two pieces of information: The name of the exception and a message. With a generic exception I could just throw an Exception but the name of the exception should already be strong enough to tell what caused it, the message is just a hint.

You should already know what happend by not even reading the message.

When I say generic exception I do not mean System.Exception

like ArgumentNullException, IndexOutOfRangeException etc. Well, any other generic exception would be just an Exception with a different name ;-)

I'm moving the exception nature-describing string from the Dynamic Type's name into a property. The amount of information remains the same. Nothing is being lost.

Have you ever used exception properties? they can never be seen anywhere. this is the least helpful place of putting additionl information.

I tried to use them... I wish I didn't :]

Yeah, I guess I'll not see what you're trying to achieve or how is it better with a custom Generic Exception since the information is not lost, nor try-catch ways are improved.

You override the ToString() to use that ExceptionKind and voila

mhm... but why should I try to recreate the string if I can create a complete full new exception type? It's much cooler then hacking the string :]

it looks nice and clean unlike any generic exception. if I saw a generic exception in production code I'd scream :-] or let the programmer support this app himself... i'm a lead dev in my team and I find complex code is not an excuse for not useing it. if it's too complex for someone else then he won't touch it. I wouldn't throw away something only because a novice dev in my team might have problems understanding it... he should learn or go ;-)

no stong words detected and no offence taken ;-) I like the discussion

this is very true what you're saying about balancing what should be learnt, or what should be dedicated more time for comprehension. but complexity is definitely a thing we always need to fight as devs since it's one of the main (some say, the only) source of defects

that's why we're team/dev leads and they're not ;-)

anyways. i see that you have a strong opinion about the reasons you wrote your code (I do not agree/fully understand them). so, sorry, I'll refrain from providing a review. I never worked with dynamic expressions, btw.

nice talking to you. appreciate your openness

unfortunatelly luxary solutions sometimes requrie drastic measures like using code generation etc. usually it's done only once and saves hours

yo, thx, take care ;-)