Sign in to follow this  
Followers 0

Should ConsoleWriteError() be merged with ConsoleWrite()?


19 posts in this topic

#1 ·  Posted

I was thinking earlier that perhaps ConsoleWriteError() should be merged with ConsoleWrite() as a parameter. The parameter values could be as such:

  • 0 - <default> Write to STDOUT
  • 1 - Write to STDERR
While this would be a script breaking change it is a logical idea as they both write to console, just different pipes. However, would there be anything that could go horrible wrong with this change that I'm missing?

My UDFs are generally for me. If they aren't updated for a while, it means I'm not using them myself. As soon as I start using them again, they'll get updated.

Current Projects:

IRC UDF, for IRC activities

[u]SafeExecute[/u], for picking and choosing what commands you want Execute to be able to run.

Share this post


Link to post
Share on other sites



#2 ·  Posted

You're missing a good reason.

Share this post


Link to post
Share on other sites

#3 ·  Posted

It's more logical not to do it.

1 person likes this

 

.

eMyvnE

Share this post


Link to post
Share on other sites

#4 ·  Posted

It's more logical not to do it.

You're missing a good reason.

Okay. Pro/Con List time.

Reasons TO merge them:

  • Easier to define where you want to write to console if in a script. (EG. You could set a ConsoleWrite() to write to STDERR by setting the flag to be @error so that if there was a success it would write to STDOUT and if NOT write to STDERR)
  • Less to type
  • Probably have the almost same source coding (then again I don't know as AutoIt isn't OSS)
Reasons NOT TO merge them:
  • Breaks scripts.
  • Makes devs do work, they already have enough

My UDFs are generally for me. If they aren't updated for a while, it means I'm not using them myself. As soon as I start using them again, they'll get updated.

Current Projects:

IRC UDF, for IRC activities

[u]SafeExecute[/u], for picking and choosing what commands you want Execute to be able to run.

Share this post


Link to post
Share on other sites

#5 ·  Posted

Easier to define where you want to write to console if in a script. (EG. You could set a ConsoleWrite() to write to STDERR by setting the flag to be @error so that if there was a success it would write to STDOUT and if NOT write to STDERR)

Set the flag to be @error huh? So when it works, it prints an error message on the standard pipe instead of the error pipe? Genius.

Makes devs do work, they already have enough

Not saying I want the AutoIt developers to do more work, but isn't that the whole point of being a developer?

Share this post


Link to post
Share on other sites

#6 ·  Posted

ImNotVeryCleverOrICouldHaveThoughtUpThisOnMyOwn("This goes to stdout." & @CRLF)

SetError(1)    ; Force an error value.
ImNotVeryCleverOrICouldHaveThoughtUpThisOnMyOwn("This goes to stderr." & @CRLF)


Func ImNotVeryCleverOrICouldHaveThoughtUpThisOnMyOwn($sMsg, $iError = @error)
    If $iError Then
        ConsoleWriteError("STDERR: " & $sMsg)
    Else
        ConsoleWrite("STDOUT: " & $sMsg)
    EndIf
EndFunc

30 seconds.

2 people like this

Share this post


Link to post
Share on other sites

#7 ·  Posted

Set the flag to be @error huh? So when it works, it prints an error message on the standard pipe instead of the error pipe? Genius.

You know what I mean.

PS: What the heck with the forums. I code enough HTML, I don't want to do it on here :|


My UDFs are generally for me. If they aren't updated for a while, it means I'm not using them myself. As soon as I start using them again, they'll get updated.

Current Projects:

IRC UDF, for IRC activities

[u]SafeExecute[/u], for picking and choosing what commands you want Execute to be able to run.

Share this post


Link to post
Share on other sites

#8 ·  Posted

Set the flag to be @error huh? So when it works, it prints an error message on the standard pipe instead of the error pipe? Genius.

You know what I mean.

PS: What the heck with the forums. I code enough HTML, I don't want to do it on here :|

If what I said isn't what you meant, then what did you mean? If you are setting the flag to error, what I described is exactly what will happen.

Share this post


Link to post
Share on other sites

#9 ·  Posted

If what I said isn't what you meant, then what did you mean? If you are setting the flag to error, what I described is exactly what will happen.

Somerandomfunc("blah")
ConsoleWrite("blah", @error)

I mean that if it is successful write to STDOUT, if not write to STDERR.

Ignoring the fact that I said

The parameter values could be as such:

because I said they COULD be as such not WOULD be OR just have the @error code negated in the ConsoleWrite code. I hate explaining the obvious but then again I should have been more clear.

My UDFs are generally for me. If they aren't updated for a while, it means I'm not using them myself. As soon as I start using them again, they'll get updated.

Current Projects:

IRC UDF, for IRC activities

[u]SafeExecute[/u], for picking and choosing what commands you want Execute to be able to run.

Share this post


Link to post
Share on other sites

#10 ·  Posted

Somerandomfunc("blah")
ConsoleWrite("blah", @error)

I mean that if it is successful write to STDOUT, if not write to STDERR.

I know exactly what you mean. I also can't understand why you can't understand what I mean. Look at these two situations and tell me if I'm still off base.

f($g)
ConsoleWrite("It worked", @error)

If it works, it prints "It worked" on STDOUT. If it didn't work, it still prints "It worked" but on STDERROR, which makes no sense.

f($g)
ConsoleWrite("It didn't work", @error)

If it works, it prints "It didn't work" on STDOUT, which makes no sense. If it didn't work, it prints "It didn't work" on STDERROR.

Share this post


Link to post
Share on other sites

#11 ·  Posted

Okay, I forgot that I'm using my own _UDF along with this :|

Here's how I have it:

; #FUNCTION# ====================================================================================================================
; Name ..........: _ConsoleWrite
; Description ...: A merge of ConsoleWrite and ConsoleWriteError
; Syntax ........: _ConsoleWrite($sText[, $fPipe = 0])
; Parameters ....: $sText              - A string value.
;                 $fPipe               - [optional] A boolean value. Default is 0.
; Return values .: None
; Author ........: Robert Maehl
; Modified ......: 02/28/2012
; Remarks .......:
; Related .......:
; Link ..........:
; Example .......: No
; ===============================================================================================================================
Func _ConsoleWrite($sText, $fPipe = 0)
If $fPipe Then
  ConsoleWrite($sText)
Else
  ConsoleWriteError($sText)
EndIf
EndFunc   ;==>_ConsoleWrite
; #FUNCTION# ====================================================================================================================
; Name ..........: _Not
; Description ...: Returns Not if needed
; Syntax ........: _Not([$fSuccess = @error[, $fCapital = 0]])
; Parameters ....: $fSuccess            - [optional] A boolean value. Default is @error.
;                 $fCapital         - [optional] A boolean value. Default is 0.
; Return values .: None?
; Author ........: Robert Maehl
; Modified ......: 02/28/2012
; Remarks .......:
; Related .......:
; Link ..........:
; Example .......: No
; ===============================================================================================================================
Func _Not($fSuccess = @error, $fCapital = 0)
If $fSuccess Then
  If $fCapital Then
   Return(" Not ")
  Else
   Return(" not ")
  EndIf
Else
  Return(" ")
EndIf
EndFunc

And doing

_ConsoleWrite("It was" & _Not() & "successful")

My UDFs are generally for me. If they aren't updated for a while, it means I'm not using them myself. As soon as I start using them again, they'll get updated.

Current Projects:

IRC UDF, for IRC activities

[u]SafeExecute[/u], for picking and choosing what commands you want Execute to be able to run.

Share this post


Link to post
Share on other sites

#12 ·  Posted (edited)

That's a pretty significant detail there. Do you see why I was saying what I was saying now?

Edited by Richard Robertson
1 person likes this

Share this post


Link to post
Share on other sites

#13 ·  Posted

That's a pretty significant detail there. Do you see why I was saying what I was saying now?

Yeah. I use the _Not() Function so often in my personal scripts I forgot I coded it. XD


My UDFs are generally for me. If they aren't updated for a while, it means I'm not using them myself. As soon as I start using them again, they'll get updated.

Current Projects:

IRC UDF, for IRC activities

[u]SafeExecute[/u], for picking and choosing what commands you want Execute to be able to run.

Share this post


Link to post
Share on other sites

#14 ·  Posted

It may be a significant detail but it doesn't change anything. Spend 3 seconds thinking about the problem and a solution presents itself.

2 people like this

Share this post


Link to post
Share on other sites

#15 ·  Posted

one more reason against it:

if an error occurs, i want to write infos about the error-details to console, else possibly the resulting values from the succesful operation.


AutoIt-Syntaxsheme for Proton & Phase5 * Firefox Addons by me (resizable Textarea 0.1d) (docked JS-Console 0.1.1)

Share this post


Link to post
Share on other sites

#16 ·  Posted

I cant believe no one has said its a bad idea because they are actually 2 different streams...


[font="Comic Sans MS"]My code does not have bugs! It just develops random features.[/font]My Projects[list][*]Live Streaming (Not my project, but my edited version)[right]AutoIt Wrappers![/right][/list]Pure randomness[list][*]Small Minds.......................................................................................................[size="1"]Simple progress bar that changes direction at either sides.[/size][*]ChristmasIt AutoIt Christmas Theme..........................................................[size="1"]I WAS BOOOORED![/size][*]DriveToy..............................................................................................................[size="1"]Simple joke script. Trick your friends into thinking their computer drive is haywire![/size][/list]In Development[list][*]Your Background Task Organiser[*]AInstall Second Generation[/list]BEFORE POSTING ON THE FORUMS, TRY THIS:
%programfiles%/AutoIt3/autoit3.chm

Share this post


Link to post
Share on other sites

#17 ·  Posted

I cant believe no one has said its a bad idea because they are actually 2 different streams...

That isn't a reason for a merged function not to exist. Two streams with a single write point can actually be very handy. For example, a logger that writes to the console and a file at the same time.

Share this post


Link to post
Share on other sites

#18 ·  Posted

Further, the fact that it is two streams is the entire point of having code branch to write to one stream or another based on a specific condition. If the two streams were the same then this thread would not exist. So yeah, you resurrected a warm corpse just to say something amazingly stupid. /slowclap

Share this post


Link to post
Share on other sites

#19 ·  Posted

10 bugs on 'code readability'.


"Straight_and_Crooked_Thinking" : A "classic guide to ferreting out untruths, half-truths, and other distortions of facts in political and social discussions."
"The Secrets of Quantum Physics" : New and excellent 2 part documentary on Quantum Physics by Jim Al-Khalili. (Dec 2014)

"Believing what you know ain't so" ...

Knock Knock ...
 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0