If an error message falls in a forest...




  • Here's a minimally redacted snippet from some C# source for a DLL:

    try
    {
        result = DoFoo();
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.ToString());
    }
    

    I can hear it now: "We're not seeing any errors -- must be a hardware problem."



  •  I'm ignorant and therefore do not see the problem.



  • DLLs generally don't have UIs.

    On the other hand, I'm mildly surprised C# lets you even compile a class library with a Console call in it.



  • What the hell do you want? It caught and handled the exception... Not well, but it was handled.



  • @blakeyrat said:

    DLLs generally don't have UIs.
    No, but they do have the ability to bubble the exception to someone who can handle it correctly.@blakeyrat said:
    On the other hand, I'm mildly surprised C# lets you even compile a class library with a Console call in it.
    I'm sure there are some code metrics tools which would produce a warning, but why would you expect a build error from the compiler?



  • @C-Octothorpe said:

    @blakeyrat said:
    DLLs generally don't have UIs.
    No, but they do have the ability to bubble the exception to someone who can handle it correctly.

    In this case, they could have just not caught it in the first place and made it the calling code's problem.

    @C-Octothorpe said:

    @blakeyrat said:
    On the other hand, I'm mildly surprised C# lets you even compile a class library with a Console call in it.
    I'm sure there are some code metrics tools which would produce a warning, but why would you expect a build error from the compiler?

    Because why would a class library have a Console object? It's the same discussion we had in the other thread about an IIS application having a Screen object.

    Obviously it's possible to do it, but I'm just saying that if you have a class library with a Console object, or an IIS application with a Screen object, you are doing something very very wrong.



  • @blakeyrat said:

    @C-Octothorpe said:
    @blakeyrat said:
    DLLs generally don't have UIs.
    No, but they do have the ability to bubble the exception to someone who can handle it correctly.

    In this case, they could have just not caught it in the first place and made it the calling code's problem.

    @C-Octothorpe said:

    @blakeyrat said:
    On the other hand, I'm mildly surprised C# lets you even compile a class library with a Console call in it.
    I'm sure there are some code metrics tools which would produce a warning, but why would you expect a build error from the compiler?

    Because why would a class library have a Console object? It's the same discussion we had in the other thread about an IIS application having a Screen object.

    Obviously it's possible to do it, but I'm just saying that if you have a class library with a Console object, or an IIS application with a Screen object, you are doing something very very wrong.

    The class library is known as the .NET CLR. And, spoiler: It's legal to output to the console, even if it's not your own. In general, this is not a good idea since you can't guarantee that there is even a console attached. However, one valid use case is MBUnit/Gallio, in which your class library full of unit tests can output to the console to add stuff to the test log.



  • @blakeyrat said:

    @C-Octothorpe said:
    @blakeyrat said:
    DLLs generally don't have UIs.
    No, but they do have the ability to bubble the exception to someone who can handle it correctly.

    In this case, they could have just not caught it in the first place and made it the calling code's problem.

    @C-Octothorpe said:

    @blakeyrat said:
    On the other hand, I'm mildly surprised C# lets you even compile a class library with a Console call in it.
    I'm sure there are some code metrics tools which would produce a warning, but why would you expect a build error from the compiler?

    Because why would a class library have a Console object? It's the same discussion we had in the other thread about an IIS application having a Screen object.

    Obviously it's possible to do it, but I'm just saying that if you have a class library with a Console object, or an IIS application with a Screen object, you are doing something very very wrong.

    I think what you're suggesting is very very wrong. How would the runtime know which libraries apply/are valid in the current context (web vs. console app vs. service). They're all just assemblies (exes, dlls), which are able to use whatever is in the .net core library (the runtime). There are smaller versions of the framework (micro framework, etc.) which have pared-down functionality, but to say that it should give you a build error is just stupid.

    Should your car not start because you're wearing a snorkeling mask?


  • @pkmnfrk said:

    The class library is known as the .NET CLR.

    Jesus fucking shit, do you people ever turn it off? Ever?

    LOOK! I'm referring to that thing you get when you open up Visual Studio and pop open the File menu and select "New Project" and then in the list you select "Class Library". I guess I didn't realize that the thing Microsoft calls a "class library" is actually a whamboozle, or whatever fucking term you think I should have used instead of "class library".

    Asshole.

    @pkmnfrk said:

    And, spoiler: It's legal to output to the console, even if it's not your own.

    I didn't say it wasn't legal, I said it's virtually 100% certain that doing so is a bug.

    @pkmnfrk said:

    In general, this is not a good idea since you can't guarantee that there is even a console attached.

    OH HEY YOU AGREE WITH ME SO GOOD THING YOU POSTED THIS TO CORRECT MY ALREADY-CORRECT TERMINOLOGY AND THEN DISAGREE WITH ME WHILE SIMULTANEOUSLY AGREEING WITH ME fuck this forum fuck it so hard



  • Maybe you're writing a DLL to share some code between console apps? In that case writing to the console is okay, I've done a few little tools that way. I've written DLLs that create WPF windows and dialogs, so multiple WPF projects could share them. This would be a WTF if the calling executable wasn't a WPF application, but in this case it was. And if something uses it that doesn't have a console, writing to the console won't cause any errors and any other issues are the caller's fault for not providing a console for a DLL that expects a console (which better be documented BTW). Without more context I'm not sure if it's a real WTF or not.

    IIRC the ONLY difference between an EXE and a DLL in the .NET world is that the EXE has a main method, and anyway I think it would be a huge WTF for the environment to allow certain things in one but not the other. Some responsibility falls on the developer to not do something retarded, and if the environment enforced stuff like this it wouldn't have much effect except to piss off the developers who found a legitimate need to work this way. The retarded developers would just find a different way to do something retarded.

     



  • @C-Octothorpe said:

    I think what you're suggesting is very very wrong.

    Ok...

    @C-Octothorpe said:

    How would the runtime know which libraries apply/are valid in the current context (web vs. console app vs. service). They're all just assemblies (exes, dlls), which are able to use whatever is in the .net core library (the runtime).

    The runtime wouldn't/doesn't have to know. How is this relevant?

    @C-Octothorpe said:

    There are smaller versions of the framework (micro framework, etc.) which have pared-down functionality, but to say that it should give you a build error is just stupid.

    An error might be strong, but it should at least be a warning.

    Visual Studio knows what type of project it is, it knows that a whamboozle can't rely on having a Console object available to it when it runs, and so it should say something about it. "Hey, uh... hey buddy? This is a class library. There's no UI. Yeah, you might luck out and accidentally end up with working code, but you probably shouldn't have code in your class library that relies on a UI." (Excuse my non-standard terminology there.)

    @C-Octothorpe said:

    Should your car not start because you're wearing a snorkeling mask?

    Probably.



  • @blakeyrat said:

    @pkmnfrk said:
    The class library is known as the .NET CLR.

    Jesus fucking shit, do you people ever turn it off? Ever?

    LOOK! I'm referring to that thing you get when you open up Visual Studio and pop open the File menu and select "New Project" and then in the list you select "Class Library". I guess I didn't realize that the thing Microsoft calls a "class library" is actually a whamboozle, or whatever fucking term you think I should have used instead of "class library".

    Asshole.

    @pkmnfrk said:

    And, spoiler: It's legal to output to the console, even if it's not your own.

    I didn't say it wasn't legal, I said it's virtually 100% certain that doing so is a bug.

    @pkmnfrk said:

    In general, this is not a good idea since you can't guarantee that there is even a console attached.

    OH HEY YOU AGREE WITH ME SO GOOD THING YOU POSTED THIS TO CORRECT MY ALREADY-CORRECT TERMINOLOGY AND THEN DISAGREE WITH ME WHILE SIMULTANEOUSLY AGREEING WITH ME fuck this forum fuck it so hard

    I like how you conveniently omit the one sentence that ties my post together (about MBUnit).



  • @rstinejr said:


    Here's a minimally redacted snippet from some C# source for a DLL:

    try
    {
        result = DoFoo();
    }
    catch (Exception ex)
    {
        Console.WriteLine(ex.ToString());
    }
    

    I can hear it now: "We're not seeing any errors -- must be a hardware problem."

    why is the try-catch around the assignment, do they expect "return" to not accept the value? Or are they using the DoFoo() method in other contexts where failure is an option? Unless DoFoo() is actually SomeOtherScope.DoFoo().



  • @blakeyrat said:

    The runtime wouldn't/doesn't have to know. How is this relevant?
    You're right, I meant the compiler (lack of proof reading).
    @blakeyrat said:
    Visual Studio knows what type of project it is, it knows that a whamboozle can't rely on having a Console object available to it when it runs
    But why not? It's just another operation/function call... Why should it throw a build warning for something which has no side-effects nor does it break any syntax/language rules. Like I said, I'm sure there are tools out there which can detect this (I know there are ones which detect empty catch blocks), but I wouldn't make it the responsibility of the compiler. Think about it, you'd need a different compiler version for each project type (asp.net, MVC, silverlight, service, class library, etc.). And somehow you'd have to be absolutely 100% sure that all dependencies (including ones resolved at run-time) would/should never touch a certain piece of functionality (Console). I think it would be easier to cut the hands off of the developers who misuse the language than do what you're proposing.



  • @C-Octothorpe said:

    But why not?

    Because you're building a .DLL. There's no UI. ... I really don't know how else to explain the concept.

    You could have a .DLL function where you pass in a stream, then it writes to the stream. Then your user code can pass in Console as your stream. That would be fine. Just blithely assuming there's a Console available is a bug.

    @C-Octothorpe said:

    Why should it throw a build warning for something which has no side-effects nor does it break any syntax/language rules.

    Because if you're doing it, you're doing something wrong.

    @C-Octothorpe said:

    And somehow you'd have to be absolutely 100% sure that all dependencies (including ones resolved at run-time) would/should never touch a certain piece of functionality (Console).

    So we shouldn't do it because it's hard? Waaaaah. Poor baby.

    Christ. No wonder software is so shitty.

    @C-Octothorpe said:

    I think it would be easier to cut the hands off of the developers who misuse the language than do what you're proposing.

    We know from experience that if developers can write a bug, they will write a bug. Anything the IDE/compiler/whatever can do to prevent the developer from writing the bug in the first place is a good thing.



  • My guess is that however their project was being run, anything written to the console (or stdout) ended up being redirected to the application's log file. I have cow-orkers who put System.out.println() instead of using the damn logger that's set up. But there's not enough context to know if that's a reasonable guess or not. Could just be good ole fashioned printf debugging left in place.



  •  blakeyrant is running to run the worlds first nanny-state compiler



  • @blakeyrat said:

    @pkmnfrk said:
    The class library is known as the .NET CLR.

    Jesus fucking shit, do you people ever turn it off? Ever?

    LOOK! I'm referring to that thing you get when you open up Visual Studio and pop open the File menu and select "New Project" and then in the list you select "Class Library". I guess I didn't realize that the thing Microsoft calls a "class library" is actually a whamboozle, or whatever fucking term you think I should have used instead of "class library".

    Asshole.

    @pkmnfrk said:

    And, spoiler: It's legal to output to the console, even if it's not your own.

    I didn't say it wasn't legal, I said it's virtually 100% certain that doing so is a bug.

    @pkmnfrk said:

    In general, this is not a good idea since you can't guarantee that there is even a console attached.

    OH HEY YOU AGREE WITH ME SO GOOD THING YOU POSTED THIS TO CORRECT MY ALREADY-CORRECT TERMINOLOGY AND THEN DISAGREE WITH ME WHILE SIMULTANEOUSLY AGREEING WITH ME fuck this forum fuck it so hard

     

    For someone who is so strongly opinionated on seemingly everything, you sure seem to have a very petite understanding about how .NET works.  Sure, writing to the Console is almost always completely useless, but why can't a dll be intended exclusively for use in Console applications?  This is still bad design, but it's valid.  Hell, the dll could be something that's exlusively used in some test suite that captures console output.  Who knows?  

    The compiler shouldn't ban you from doing something just because it's stupid. The compiler only needs to detect syntax errors, not to correct bad logic or bad design.

     



  • @ShatteredArm said:

    For someone who is so strongly opinionated on seemingly everything, you sure seem to have a very petite understanding about how .NET works.

    Relevance?

    @ShatteredArm said:

    Sure, writing to the Console is almost always completely useless, but why can't a dll be intended exclusively for use in Console applications?

    In that case why bother with a DLL in the first place?

    A DLL is a shared library. A shared library doesn't know or care what code is calling it. It doesn't know or care whether the calling code has a console UI or not. It doesn't know or care whether the calling code is a Windows Service, or a webpage, or a fucking cellphone.

    If you make it dependent on having a Console object,
    1) You shouldn't be compiling into a shared library, it's the wrong project type to solve your problem, or
    2) You have no fucking clue what a "shared library" is in the first place and should be digging ditches for a living, or
    3) You're ok with buggy-ass software and don't give a shit whether or not you're writing quality code.

    All of those options stink. Your example is option one.

    @ShatteredArm said:

    This is still bad design, but it's valid.

    What's your definition of "valid"?

    @ShatteredArm said:

    The compiler shouldn't ban you from doing something just because it's stupid.

    Yes it should.

    @ShatteredArm said:

    The compiler only needs to detect syntax errors, not to correct bad logic or bad design.

    You went from talking about what the compiler should do to talking about what it needs to do. You do realize those things are not mutually-exclusive, right? It needs to detect syntax errors, but it should warn people who are doing intensely stupid things not to do intensely stupid things.



  • @blakeyrat said:

    Jesus fucking shit, do you people ever turn it off? Ever?

    I suspect most of them are Irritation Vampires who feed on the irritated feelings of Normals.



  • All this argument about writing to the console from a DLL...

    If C had raised compile errors when writing to the console from a library, the very useful curses could never have been be created...



  • @blakeyrat said:

    DLLs generally don't have UIs.

    On the other hand, I'm mildly surprised C# lets you even compile a class library with a Console call in it.

    afaik you can theoretically have your whole application with all the forms and logic coded in DLL, with the actual .exe just making it run by calling some function along the lines MyDll.RunApp().

    i once coded a custom electronic trading strategy system, which was done by coding a C# dll and then sticking it into the trading app. i needed to see some debug info and have many extra settings, so i made the dll instantiate a console and a winforms form in the Init() function that the trading app was calling when starting up the strategy. it worked with no problems at all.



  • @ekolis said:

    All this argument about writing to the console from a DLL...

    If C had raised compile errors when writing to the console from a library, the very useful curses could never have been be created...

    Well, this ain't C.. .NET has a real GUI. There's no need to poorly mimic one using the console.

    Got any other straw men?



  • @SEMI-HYBRID code said:

    @blakeyrat said:
    DLLs generally don't have UIs.

    On the other hand, I'm mildly surprised C# lets you even compile a class library with a Console call in it.

    afaik you can theoretically have your whole application with all the forms and logic coded in DLL, with the actual .exe just making it run by calling some function along the lines MyDll.RunApp().

    i once coded a custom electronic trading strategy system, which was done by coding a C# dll and then sticking it into the trading app. i needed to see some debug info and have many extra settings, so i made the dll instantiate a console and a winforms form in the Init() function that the trading app was calling when starting up the strategy. it worked with no problems at all.

    He's not saying you can't do that; he's saying it's wrong. And, so far, I haven't seen any good argument to refute his claim.



  • I hate to say it but, I've been bad and done UI from a DLL before as well.

    An engine that was very locked down needed some extensions to support settings/multiple savegames (yep really) so a DLL ended up being written in C++ to handle all that. It was not pretty. To log what was going on a terminal window had to be opened by the DLL as there didn't seem to be any real way to interface with the debugging tools in the engine itself, and short of logging to text files there was no way around.

    All of which was removed for production of course.



  • @blakeyrat said:

    @ShatteredArm said:
    Sure, writing to the Console is almost always completely useless, but why can't a dll be intended exclusively for use in Console applications?

    In that case why bother with a DLL in the first place?

    I'm trying to understand the frame of reference that begat this question, and the only thing I can come up with is that you're responding Jeopardy style, since he just gave you the answer.

    @blakeyrat said:

    A DLL is a shared library. A shared library doesn't know or care what code is calling it. It doesn't know or care whether the calling code has a console UI or not. It doesn't know or care whether the calling code is a Windows Service, or a webpage, or a fucking cellphone.

    Sort of. I don't think any of this applies to the OP, but that's never stopped anyone around here before. The DLL obviously has a purpose, so there are some assumptions about what's going on. Maybe this particular dll was meant to be used in some sort of powershell scripting environment. That seems like perhaps the most reasonable place to have console output. But your assumption that code has to be designed to be used in any environment is just...wrong.

    @blakeyrat said:

    If you make it dependent on having a Console object,

    1) You shouldn't be compiling into a shared library, it's the wrong project type to solve your problem, or

    2) You have no fucking clue what a "shared library" is in the first place and should be digging ditches for a living, or

    3) You're ok with buggy-ass software and don't give a shit whether or not you're writing quality code.

    I think that probability says that you're right in the case of the OP, but you're still full of shit, since you have no idea what the purpose of the code is. Well, mostly I think #3 applies, but #s 1 and 2 are just another demonstration of your parochial way of life.



  • The only real reason I can see allowing the Console class in a DLL is because the only way to get stdout, stderr, and stdin is through the Console class.



  • OH HEY BOOMZILLA!

    @boomzilla said:

    But your assumption that code has to be designed to be used in any environment is just...wrong.

    Not "code", but "code in a shared library". That is the point of a shared library.

    If you want code to have a UI, don't put it in a shared library. If you want your shared library to output some text, pass it in a stream to output to. If you really want it to output to the Console, pass in the Console's stream.

    I honestly don't understand why this is so difficult.



  • I'd have to agree with blakey here. I've always found it a little bit silly that Console is static in C#; would much prefer it to actually be an instance of an object so that if the UI doesn't want to give a handle to that object to another class (whether in a library or otherwise) then it can keep it's grubby hands off the interface.

    While I wouldn't be so extreme as to say a DLL should never touch the UI or have UI logic in it, I would certainly agree that it shouldn't touch any part of the UI without the calling code explicitly handing it a reference to the UI it is going to work on. By all means a DLL can be passed Console.Out and Console.In and then do whatever it's meant to do with them, because at that point your UI-layer has essentially requested that the shared library perform actions on the UI itself. For a shared library to make an assumption, unsolicited by the calling code, that it can just go straight to the user interface without the UI layer being involved is just bad design. And if a bad design which is typically indicative of an error can be detected by the IDE/compiler then I agree a warning is a very good way to deal with it.



  • @fyjham said:

    I'd have to agree with blakey here. I've always found it a little bit silly that Console is static in C#; would much prefer it to actually be an instance of an object so that if the UI doesn't want to give a handle to that object to another class (whether in a library or otherwise) then it can keep it's grubby hands off the interface.

    While I wouldn't be so extreme as to say a DLL should never touch the UI or have UI logic in it, I would certainly agree that it shouldn't touch any part of the UI without the calling code explicitly handing it a reference to the UI it is going to work on. By all means a DLL can be passed Console.Out and Console.In and then do whatever it's meant to do with them, because at that point your UI-layer has essentially requested that the shared library perform actions on the UI itself. For a shared library to make an assumption, unsolicited by the calling code, that it can just go straight to the user interface without the UI layer being involved is just bad design. And if a bad design which is typically indicative of an error can be detected by the IDE/compiler then I agree a warning is a very good way to deal with it.

    It seems like, as Blakey says, you should only pass abstractions like streams into a shared library. For one, it makes unit testing easier since you don't have references to Console all over the place.



  • Thank you.

    I think the critics here are disagreeing with me because they see "Blakeyrat" in the name field, and (hopefully!) not because they genuinely feel that my idea is a bad one.



  • @blakeyrat said:

    You could have a .DLL function where you pass in a stream, then it writes to the stream. Then your user code can pass in Console as your stream. That would be fine. Just blithely assuming there's a Console available is a bug.
     

    I agree. One could argue that the problem is the fact that "Console" is not actually an Object per se but rather a static class in the System namespace, so anybody can fuck with it if they so desire. At the very least I think it should require a person making a class library to, say, add a reference or dig down into some object heirarchy to get at the console. That way at least they were given a chance to not fuck up and they blew it.

     

    Also: the Console class <could> theoretically check the calling assembly and see if it's a DLL and, if running in debug mode, it could pour molten lead on the programmer, and perhaps play some clips "NO BAD PROGRAMMER" and whatnot.  Actually that doesn't seem like a terrible idea. And if a DLL really wants to write the console, then it can request the Console.out value from the client. Perhaps with a callback named "givemeafuckingconsole" or something. Then the executable programmer can respond to this event by either telling the library to go fuck it's hat, or pass along it's OutputStream for the library to use as it's plaything.



  • @blakeyrat said:

    OH HEY BOOMZILLA!

    @boomzilla said:

    But your assumption that code has to be designed to be used in any environment is just...wrong.

    Not "code", but "code in a shared library". That is the point of a shared library.

    Yes, "shared." Which is not necessarily the same as "must be usable in any environment." You could substitute "class" for "dll" in your argument and it would be exactly the same, because the point of a shared library is simply to be able to reuse the code. Another purpose of a particular shared library may be to be able to use it in multiple environments, but that's not inherent in the concept of a shared library itself.

    @blakeyrat said:


    If you want code to have a UI, don't put it in a shared library. If you want your shared library to output some text, pass it in a stream to output to. If you really want it to output to the Console, pass in the Console's stream.

    I honestly don't understand why this is so difficult.

    It's not hard to understand, and I do agree with this, but then this is your straw man, not my argument. And it's orthogonal to the concept of "shared library."



  • @ekolis said:

    All this argument about writing to the console from a DLL...

    If C had raised compile errors when writing to the console from a library, the very useful curses could never have been be created...

     

    I came here to mention that. The only time it makes sense to write to the console from a shared library is when it's a shared library [i]for the purpose of writing to the console[/i]. (And things that don't have a console don't/shouldn't import it because it isn't useful for them.)

    You can write shared libraries for all sorts of useful purposes. So why not that?



  • @delta534 said:

    The only real reason I can see allowing the Console class in a DLL is because the only way to get stdout, stderr, and stdin is through the Console class.
    As far as I'm concerned, the only good solution to this issue is not to use Console directly from inside DLL code, but to pass in the stdout, stderr and/or stdin streams as parameters to the corresponding DLL methods that need to write stuff to some output device. Then it is the callers job to make sure an output device is available and initialized as needed. And whether that is a Console window or a log file, then, doesn't matter in the slightest way. The DLL should not rely on the operating system to do stuff like this for it. I completely support blakeyrat in his position.



  • @morbiuswilters said:

    He's not saying you can't do that; he's saying it's wrong. And, so far, I haven't seen any good argument to refute his claim.
     

    okay, i admit that i wrote my post before reading the whole thread, but at the same time i must say that after writing the post and reading the thread to it's (then-current) end, i so far haven't seen any good argument to support the claim it's wrong. the only argument i've seen is "you most likely don't know what you're doing" which i agree is wrong - when programmingin general."it's much more likely that you'll fuck something up when doing this" doesn't seem to me like a good argument to prevent me from doing anything.



  • Let's see if this fans the flames or helps.  :)

    A DLL does stuff, who cares if this is .Net or C++ or whatever.  It does stuff andproduces results.  That is it's job.  It's job is not to decide how those results should be displyed, that is the job of the presentation tier and wether that tier uses a web page, a service front end, the console or nothing at all is not a dependency on the functional library.

    Now an you have a few DLL's whos job is providing the proper interface for your presentation?  Yes, you could have one for console or one for wondows forms but hte functional DLL doesn't know or care, it simply produces it's results and hands those results to the presentation tier that then can use the presentation DLL's to display the data in the appropriate fashion.  Mixing your presentation with your functionality would be a problem here.

    As an example this shows where having console out would be valid in a dll, because it provides switchable UI's for your application



  • @SEMI-HYBRID code said:

    @blakeyrat said:
    DLLs generally don't have UIs.

    On the other hand, I'm mildly surprised C# lets you even compile a class library with a Console call in it.

    afaik you can theoretically have your whole application with all the forms and logic coded in DLL, with the actual .exe just making it run by calling some function along the lines MyDll.RunApp().

    i once coded a custom electronic trading strategy system, which was done by coding a C# dll and then sticking it into the trading app. i needed to see some debug info and have many extra settings, so i made the dll instantiate a console and a winforms form in the Init() function that the trading app was calling when starting up the strategy. it worked with no problems at all.

     

    This is how I've always done modular or auto-updated applications. Write an exe that's just a small entry point which checks for updates and then calls into DLLs where all your application logic actually resides. The exe can download and overwrite the DLLs before they're loaded, but once they're loaded the runtime has a lock on them so they can't be modified which is why a single exe application can't update itself easily. Sometimes they write debug information to the Console because it's stuff I want to monitor during a debug session (it'll pop up in the Visual Studio output window that way) but the user doesn't need to know or care and writing to a log file is more work. Usually these get removed before the application moves into production.

    Oh, and by the way there is no such thing as an exe in the Silverlight world. All output gets compiled to DLLs. Updating the compiler to prevent UI in a DLL would make Silverlight applications suddenly fail to build. So if writing UI in a DLL is a bug then Microsoft messed up badly. Or blakey is wrong. Or both. Take your pick.

    Also, every third-party UI library I've ever used is compiled to a DLL. Actually every first-party Microsoft UI library I've used was also a DLL. Such as System.Windows. Even the Console class itself is in a DLL called mscorlib. So enforcing blakey's proposed compiler rules would break the entire .NET Framework and make the most complicated compiler ever.

    If none of these should be a DLL, the only other option is to compile them to an EXE, which can still be referenced exactly the same as a DLL in Visual Studio. But the you have an executable that shouldn't actually do anything when you run it. What exactly should a plugin for my company's product do if it's compiled to an EXE and executed? That's way more of a bug than having UI code in a DLL.

    There's a third option other than compiling to an EXE instead of a DLL, and that's distribute all libraries in source form and force developers to add source to their projects instead of referencing an external assembly. This is what many third-party iOS frameworks do because Apple disallows dynamic linking and static linking requires a specific planetary alignment to work correctly. And it sucks. Horribly.

     



  • @mott555 said:

    Oh, and by the way there is no such thing as an exe in the Silverlight world. All output gets compiled to DLLs. Updating the compiler to prevent UI in a DLL would make Silverlight applications suddenly fail to build. So if writing UI in a DLL is a bug then Microsoft messed up badly. Or blakey is wrong. Or both. Take your pick.

    I think we can safely assume it's another case of him over generalizing for emphasis and then blaming others for actually reading what he wrote.



  • @morbiuswilters said:

    @SEMI-HYBRID code said:
    @blakeyrat said:
    DLLs generally don't have UIs.

    On the other hand, I'm mildly surprised C# lets you even compile a class library with a Console call in it.

    afaik you can theoretically have your whole application with all the forms and logic coded in DLL, with the actual .exe just making it run by calling some function along the lines MyDll.RunApp(). i once coded a custom electronic trading strategy system, which was done by coding a C# dll and then sticking it into the trading app. i needed to see some debug info and have many extra settings, so i made the dll instantiate a console and a winforms form in the Init() function that the trading app was calling when starting up the strategy. it worked with no problems at all.
    He's not saying you can't do that; he's saying it's wrong. And, so far, I haven't seen any good argument to refute his claim.
    I won't argue that it makes sense to access the console from a DLL, but there are some common and useful patterns where DLLs create UIs. Applications that have a plug-in system need to load the plug-in into the current process and if the plug-in is a wizard or a property page, then its whole purpose in life is to display a user interface. Sometimes the DLLs are masked a bit - for example, .ocx files (COM controls) are really just COM DLLs that implement a specific interface. Sometimes, they have a plain DLL file extension, like MMC snap-ins (example here).


  • @KattMan said:

    A DLL does stuff, who cares if this is .Net or C++ or whatever.  It does stuff andproduces results.  That is it's job.
     

    we may have different definitions of "doing stuff" then, because to me "displaying the data" falls into this cathegory just fine. besides, what is DirectX? Managed DirectX? OpenGL? And about every other presentation LIBRARY out there? worse than that, these DLLs interface directly with your hardware (as a fuckload of other does), making assumptions and/or requirements about its capabilities, which to me would be even worse than making a simple assumption that (software) console is present. if the reasoning behind why having DLL handle presentation layer (or using one) would be right, then innumerable libraries would become "incorrect", or unusable/futile, in a pursuit to make them "correct". including all the drivers that your computer uses.

    i can't help myself but see this argument as a battle between "MVC IS TEH ONLY WAY!" and "what's wrong with using the tools at your disposal in a way you can use them to produce desired results?

     

    mvc is NOT teh only way, it's a human construct that was made to make complex applications more readable and maintainable. but it is still a human construct, a principle that was meant as a tool, not as a religion. and as with all the tools, (not)using it is not inherently good or bad, it all depends on a context, case-for-case basis. not being able to diverge from existing dogmas just because... well...why, really? seems to me like the exact opposite of reinventing the wheel, and equally bad of an attitude. there's a reason why not every application uses the MVC model, and it's not always bad programmers. you don't need a nuclear bomb to flatten an area so you can build a house there, and it's a stupid idea to do it just because you didn't ever use anything else to solve problems and you're afraid to think for yourself and try new, more suitable and/or convenient things/methods/tools.



  • Don't feel the need to dcompletly quote you SEMI-HYBRID, but you are saying really what I am saying.  My example was a means of showing how DLL's could be UI's.  Other examples were given, (COM Controls come to mind, MMC snap in's also)  No MVC is NOT the only way, and honestly in my 17 years of experiance have rarely used MVC in a real world environment.  Now I have created plug-ins and snap ins that had to carry UI components with them.

     



  • I've never actually thought about this, but semantically blakey is correct. A library that's going to be interfacing with other components, in a "black box" environment, should make no assumptions about what it does or does not have access to.

    The decision by Microsoft to put the Console class into the System namespace is, in hindsight, not the best one. What they probably should have done was put System.Console into its own library, which would be auto-referenced by all project types except class libraries. But there's no way to prevent anyone from manually referencing the System.Console DLL in their class library, so we're effectively back to square one. Add to that the fact that .NET executables are effectively just bootstrap wrappers around a class library, that invoke a specific method when run = effectively everything in .NET is a library = having the compiler warn about System.Console being used in a "class library" would break everything.

    BTW, I checked the source of System.Console, and if it can't get hold of the standard Win32 console, the In/Out/Error properties simply return wrappers around Stream.Null - effectively turning reads and writes to those streams into nops. So Microsoft definitely considered this case and made sure those using System.Console in the wrong context, do not have enough rope to hang themselves with.



  • @The_Assimilator said:

    What they probably should have done was put System.Console into its own library, which would be auto-referenced by all project types except class libraries. But there's no way to prevent anyone from manually referencing the System.Console DLL in their class library, so we're effectively back to square one.

    There's only so much you can do to prevent people from shooting themselves in the foot. But yes, not including Console in class library projects would have been a good decision.

    @The_Assimilator said:

    Add to that the fact that .NET executables are effectively just bootstrap wrappers around a class library, that invoke a specific method when run = effectively everything in .NET is a library = having the compiler warn about System.Console being used in a "class library" would break everything.

    1. I never said the compiler has to give the warning; there's this thing called an "IDE"

      2) Maybe the compiler is too stupid and, if given access to more information, could be smarter

    @The_Assimilator said:

    BTW, I checked the source of System.Console, and if it can't get hold of the standard Win32 console, the In/Out/Error properties simply return wrappers around Stream.Null - effectively turning reads and writes to those streams into nops. So Microsoft definitely considered this case and made sure those using System.Console in the wrong context, do not have enough rope to hang themselves with.

    Yet another reason writing to Console in a class library is 99.99% certain to be a bug. "My Console write disappeared!"



  • @KattMan said:

    but you are saying really what I am saying
     

    then i understood incorrectly what you're saying, sorry, sleep deprivation and stress starts to take it's toll



  • @The_Assimilator said:

    I've never actually thought about this, but semantically blakey is correct. A library that's going to be interfacing with other components, in a "black box" environment, should make no assumptions about what it does or does not have access to.
     

    okay, then there's a question - does writing to console prevent the library from being a black box/working in a black box? how do you know the dll is not writing into console it has created for itself in the init function? what part of the snippet presented in the OP definitely says that it's using a console that it assumes is already there, created by someone else in advance?



  • OK, quick 2 cents... everything has stdout available....that is what Console is a wrapper for...
    (Stdout, stderr and stdin)

    Booo... editing on android is aweful



  • @SEMI-HYBRID code said:

    we may have different definitions of "doing stuff" then, because to me "displaying the data" falls into this cathegory just fine. besides, what is DirectX? Managed DirectX? OpenGL? And about every other presentation LIBRARY out there? worse than that, these DLLs interface directly with your hardware (as a fuckload of other does), making assumptions and/or requirements about its capabilities, which to me would be even worse than making a simple assumption that (software) console is present. if the reasoning behind why having DLL handle presentation layer (or using one) would be right, then innumerable libraries would become "incorrect", or unusable/futile, in a pursuit to make them "correct". including all the drivers that your computer uses.

    i can't help myself but see this argument as a battle between "MVC IS TEH ONLY WAY!" and "what's wrong with using the tools at your disposal in a way you can use them to produce desired results?

    First of all, I don't give a shit about MVC and I generally don't use it. That out of the way...

    I've been thinking about this this morning, and so I've come up with a rephrasing that should make even the most dickweedy of the dickweeds happy:

    A shared library should never use UI elements (including the Console) that were not passed to it by the calling code, and were not created by the library itself.

    This excuses WinForms and DirectX, since they create their UI (at the urging from the calling code) before displaying anything on them, and also still demonizes shared libraries that contain the Console class, or call MessageBox.Show() in the middle of a function.

    I'm sure you're all itching at the bit to pedantic dickweed away and fine some obscure edge-case that this phrasing doesn't cover. Go for it. Knock yourself out. I'll be over here getting wasted on whiskey.



  • @blakeyrat said:

    A shared library should never use UI elements (including the Console) that were not passed to it by the calling code, and were not created by the library itself.

    This excuses WinForms and DirectX, since they create their UI (at the urging from the calling code) before displaying anything on them, and also still demonizes shared libraries that contain the Console class, or call MessageBox.Show() in the middle of a function.

    I'm sure you're all itching at the bit to pedantic dickweed away and fine some obscure edge-case that this phrasing doesn't cover. Go for it. Knock yourself out. I'll be over here getting wasted on whiskey.

    I'll drink with you, this should be part of the best practices anywhere you go, Yes you can break it, but you shouldn't, and cut off your fingers if you do.  Falls into everything I agree with.

     



  • @morbiuswilters said:

    @blakeyrat said:
    Jesus fucking shit, do you people ever turn it off? Ever?

    I suspect most of them are Irritation Vampires who feed on the irritated feelings of Normals.

    Christ, if you're going to give blackey a beejer, at least have the decency to not do it in public...


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.