Hello guys
Hello guys,
NameOf .NET-like compiler magic (intrinsic) function would eliminate a lot of hand-written exception messages from several units. Is that function likely to come in any future release?
:D
NameOf .NET-like compiler magic (intrinsic) function would eliminate a lot of hand-written exception messages from several units. Is that function likely to come in any future release?
:D
Out of curiosity: what is that you can do with NameOf (design time) that you can't with ClassName (run time)?
ReplyDeleteAndrea Raimondi I guess this is about getting the name of the current method, not just the class.
ReplyDeletePrime example? Raising an exception:
ReplyDeleteif not Assigned(Parameter) then
raise EArgumentNilException.CreateFmt('Parameter %0:s was nil.', [NameOf(Parameter)]);
Andrea Raimondi Thomas Mueller NameOf retrieves the name of anything. Variables, Methods, Arguments, ...
ReplyDeleteLets assume we have this
procedure foo( Whatever: TObject );
begin
if not Assigned( Whatever ) then
raise EArgumentNilException.Create( 'Whatever' );
end;
and we refactor the argument name
procedure foo( AObject: TObject );
begin
if not Assigned( AObject ) then
raise EArgumentNilException.Create( 'Whatever' );
end;
You see the "failure"?
With NameOf:
procedure foo( Whatever: TObject );
begin
if not Assigned( Whatever ) then
raise EArgumentNilException.Create( NameOf( Whatever ) );
end;
this will not happen. You have a check on compile time :o)
https://plus.google.com/+StefanGlienke/posts/AsGHSLF4rTX
ReplyDeleteD'oh! You must really forgive me for being obnoxious :) but I thought we already had something eerily similar in the form of MadExcept, EurekaLog, etc. Well, yeah, they probably don't get down to the parameter, yet they give you fairly heavy hints on what's wrong. Besides that, I also thought that the exception message would have to be something useful to the user. I can see how this could be useful in logging, however, I thought that you would account for that kind of situation in the method itself. But that is me and maybe I am just too old :)
ReplyDeleteOliver Münzberg - imho there are multiple "failures" in your example. The first is a poorly named parameter, the second is a refactoring to an even worse named parameter and the third is an exception message with a reference to an implementation detail.
ReplyDeleteI understand your example was a contrived example, but all it is an example of is compounded poor coding, not a real problem requiring this solution.
/sub
ReplyDeleteJolyon Direnko-Smith Implementation details in exception messages are a very good thing: when an unhandled exception occurs, it means there is something wrong with your implementation, and the more details you can put in the message that's going to be reported back to the developers, the easier it is for them to track down and fix the problem.
ReplyDeleteMason Wheeler Obviously the redundant qualification that I omitted is "irrelevant and meaningless". i.e. incorporating the actual name of the parameter is redundant if the message identifies the value that the parameter represents rather than simply referencing the parameter name without regard for the "quality" of that name.
ReplyDeleteA parameter name of "aObject" is unlikely to be meaningful (except in the case of a framework that operates on objects). The parameter name should be meaningful and using "nameof()" in the contrived example simply propagates a meaningless detail of the implementation into a meaningless error message.
Identifiable, yes, but meaningless.
A meaningful message still meets the criteria of identifying the relevant implementation detail (the error message can be just as easily located and thus identify the cause of the error) but it does so in a way that is not only useful to the developer but also more likely to be meaningful to the poor, unfortunate user who sees the error in the event that it turns out to be unhandled.
ime Joe User's typical response to "scary" error messages (full of meaningless technical mumbo jumbo of no relevance to the user) is to simply ignore them, deciding that it is just the computer having one of those days. A "brain fart" is a common expression for such errors.
"EArgumentNilException in aObject of Foo()"
== close the app, try again and hope it goes away.
"An unexpected error occurred in Foo(). A customer is required to be identified."
== "Oh, I should tell the developer about this."
(or even, oh I see - I didn't select a customer before doing operation X [ yes probably a bug that the exception indicates, but maybe if I select a customer first then this error won't occur....] )
Also, there is no way of classifying an exception as handled or unhandled when it occurs. That can only be determined much later. ;)
Jolyon Direnko-Smith Just to clarify: The example was just an example how NameOf can be used and what benefit you can get from it.
ReplyDeleteI could have used some meaningful methods and names inside a very smart framework with 100+ units ... but that would just hide the information I tend to give.
IMHO a discussion about exception handling is not useful inside this post. Feel free to start a new discussion post about exceptions and handling of them.