首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

当逻辑看起来是正确的时候,为什么我的函数不工作?

当逻辑看起来是正确的时候,函数不工作可能是由于以下几个原因:

  1. 语法错误:函数中可能存在语法错误,例如拼写错误、缺少分号等。这些错误会导致函数无法正确解析和执行。可以通过仔细检查代码并使用调试工具来定位和修复语法错误。
  2. 参数问题:函数可能需要传入特定的参数,但是在调用函数时未正确传入参数或者传入的参数类型不匹配。可以检查函数定义和调用的参数是否一致,并确保参数类型正确。
  3. 变量作用域问题:函数内部使用的变量可能未在函数内部正确声明或赋值。这可能导致函数无法访问或使用这些变量,从而导致函数不工作。可以检查变量的作用域和赋值情况,确保函数内部可以正确访问所需的变量。
  4. 逻辑错误:函数中的逻辑可能存在错误,导致函数无法按照预期工作。可以仔细检查函数的逻辑流程,确保每个步骤都符合预期,并且没有遗漏或错误的条件判断。
  5. 异常处理:函数可能在执行过程中遇到异常情况,但是没有进行适当的异常处理。这可能导致函数提前终止或产生错误结果。可以添加适当的异常处理机制,例如使用try-catch语句来捕获和处理异常,确保函数能够正常执行。

总结起来,当逻辑看起来是正确的时候,函数不工作可能是由于语法错误、参数问题、变量作用域问题、逻辑错误或异常处理不当等原因导致的。在排查问题时,可以逐步检查和排除这些可能性,以找到并修复函数不工作的原因。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

刚做测试工作一年时候怎样

03 关于工作 当时发offer测试,后来入职后发现是个运维活。组长测试经理,算就俩测试,刚开始写过验收文档,用户操作手册,测试用例,测试计划,写完就写完了,并没人告诉对不对。...然后就去查服务器日志看哪个服务死了没启动,并仔细排查,帮客户解决。 先期客服,给我打电话,告诉哪个服务不好使了,后来客服直接把电话给了客户,莫名成了客服,每天电话响时候最慌。...一件事刚开始时候,也是毫无成就感时候,挫败感极强。但如果坚持下去,永远没有能得到自信那一天,一辈子都会有挫败感。 刚开始确实很难受,但是每次师傅都认真给我说问题出在哪。...,看到这你可能没想到六哥,在工作一年时候,测试用例都不会写。...但如果坚持下去,永远没有能得到自信那一天,一辈子都会有挫败感。 坚持做自己认为对事,至于是对错,并不重要,时间长了,自然就会有有分晓。

60910

踩坑经验 | 为什么建议在power bi 写dax时候用search函数

12 2023-11 踩坑经验 | 为什么建议在power bi 写dax时候用search函数 分享一个踩坑经验,为什么建议大家在dax中使用search函数~ LEARN MORE 图片由通义万相绘制...没费多大力气,就定位到了,数据本身正确,但是行级别安全性出现问题了。简单来说,就是返回结果空值。 是不是感觉很神奇?明明什么都没有改,为什么dax函数突然就报空了么?...search函数虽然好用,但是遇到这种情况真可谓让人崩溃,毕竟一般情况下,咱也想不到另一个函数返回值会发生变化。于是就翻车了。...不过仔细想想,这种情况其实并不是什么罕见情况,虽然看起来这次确实比较特殊,一个后台调整导致变化打得人措手不及。...:AIGC相关,包括但不限于教程、使用评测 周二:数据处理技术分享、代码分享 周三:工作效率提升工具/技巧,办公自动化等 周四:读书笔记系列,分享读书心得和要点 周五:聊聊职场,包括但不限于求职面试

36740
  • 机器学习笔记之为什么逻辑回归损失函数交叉熵

    逻辑回归反向传播伪代码; 大家可以思考下能不能回答/推导出,但这次讨论问题为什么逻辑回归损失函数交叉熵? 初看这个问题感觉很奇怪,但是其中知识包含了LR推导与理解。...在个人看来,可以从两个角度看待这个问题: ''' 【1】从极大似然估计角度可以推导出交叉熵; 【2】从KL散度(熵角度)去理解; ''' 0x01 极大似然估计 对于逻辑回归,我们一般通过极大似然估计来求解参数...首先假设两个逻辑回归两个条件概率: ? 学习时,采用极大似然估计来估计模型参数,似然函数为: ? 对数似然函数(采用对数似然函数是因为上述公式连乘操作易造成下溢)为: ?...简单来说,「KL散度衡量两个概率分布差异」。 逻辑回归模型最后计算结果(通过sigmoid或softmax函数各个分类概率(可以看做各个分类概率分布)。...因为交叉熵越大,KL散度越大,也可以用交叉熵来衡量两个概率分布之间距离,所以逻辑回归使用交叉熵作为逻辑回归损失函数

    1.1K10

    实践单元测试姿势

    就是完整检测代码单元功能逻辑,找出代码单元本身所有功能逻辑错误,具体来说,就是检测对数据各种分支是否考虑全面,处理是否正确。形象地说,单元测试目的就是验证:无论别人怎么样,总是对。...“别人”,指相关代码或环境,“”,指正在编写或测试代码单元。 单元测试为啥能提高代码质量呢?由于每个单元有独立逻辑,做单元测试时需要隔离外部依赖,确保这些依赖不影响验证逻辑。...姿势2:干掉单元测试天敌—可测性 单元测试效益特别高,方法看起来也很简单,但却尝试多,成功实施少,为什么呢?主要原因在于难于突破可测性问题。...[1499416785556_7382_1499416906094.png] 为什么代码会不可测呢?一般来说,这些原因导致了代码可测性差:项目很复杂,开发流程规范,耦合度很高。...一个函数要“可测”,要做到两方面:第一能够独立运行,第二要能够覆盖输入分类。为什么要覆盖输入分类呢?因为单元测试目标覆盖代码单元功能逻辑,要做到覆盖功能逻辑,就要覆盖输入所有分类。

    2.4K11

    干货 | 从资深软件工程师学到避坑大法

    进入代码审查环境时候才明白为什么命名这么难。 在计算机科学里有两个难题:内存不足、命名、以及差一(off-by-one)错误。...发现命名好另一个好处:如果它看起来太长了,就像 LayoutComponent 包含了很多业务逻辑层,就知道时候要重构了,因为业务逻辑层并不属于这里。...如果忘记了这部分代码,之后又回到了代码工作上,没有注释的话不能重新创建上下文,可能只会想:「为什么他们要这么写?这没有任何意义……哦,等等,。」 这里就是开发文档和注释该出现地方。...尝试基于已有代码进行工作,但是资深工程师会尝试解决掉它——全部删除。一个永远无法到达 if 声明?一个不应该调用函数?是的,都消失了。 至于我呢?只会把函数写在最上面。...认为测试一种文档,对代码假设文档。测试会告诉(或之前的人)他们预想代码如何工作,以及他们预期哪里会出错。 所以,写测试时,我会记住: 记录如何使用测试时用到类/函数/系统。

    57120

    为什么程序员都不喜欢使用 switch ,而是大量 if……else if ?

    语法正确逻辑错误 缺点二 .死板语法 缺点三 .需要子函数来处理分支 switch 优点 ---- 请用5秒钟时间查看下面的代码是否存在bug。 ?...语法正确逻辑错误 这就是第一个理由为什么程序猿很少使用switch来做条件判断,对于新手来说忘记写break实在再普通不过了,就算是老猿忘记写也是时有发生事情,而这个语法错误在诸多语法检查器上没有办法检查出来...上面的代码为了保证正确添加了else做一个逻辑保证,其实如果写else,这段代码也不会发生逻辑错误,而且一旦忘记写花括号时候,语法编译器会提示添加,甚至可以使用eslint这种工具强制使用花括号...在早起电脑代码中没有子函数概念,那时候都是用goto随意跳转,你想去第10行代码,很简单goto 10就可以了。...这种编程思维在C早期阶段还是一直受到影响,因此早期C也没有子函数,都是一堆逻辑处理混乱在一起,goto满天飞,所以那时候你没有一个最强大脑写不了程序

    46020

    为什么程序员都不喜欢使用switch,而是大量 if……else if ?

    语法正确逻辑错误 这就是第一个理由为什么程序猿很少使用switch来做条件判断,对于新手来说忘记写break实在再普通不过了,就算是老猿忘记写也是时有发生事情,而这个语法错误在诸多语法检查器上没有办法检查出来...上面的代码为了保证正确添加了else做一个逻辑保证,其实如果写else,这段代码也不会发生逻辑错误,而且一旦忘记写花括号时候,语法编译器会提示添加,甚至可以使用eslint这种工具强制使用花括号...对于我们这么潇洒自如程序猿来说,这种限制实在太麻烦了,用if的话,别说是常量了,函数都可以,真正做到方便快捷。...在早起电脑代码中没有子函数概念,那时候都是用goto随意跳转,你想去第10行代码,很简单goto 10就可以了。...这种编程思维在C早期阶段还是一直受到影响,因此早期C也没有子函数,都是一堆逻辑处理混乱在一起,goto满天飞,所以那时候你没有一个最强大脑写不了程序

    58350

    为什么程序员都不喜欢使用switch,而是大量 if……else if ?

    语法正确逻辑错误 这就是第一个理由为什么程序猿很少使用switch来做条件判断,对于新手来说忘记写break实在再普通不过了,就算是老猿忘记写也是时有发生事情,而这个语法错误在诸多语法检查器上没有办法检查出来...上面的代码为了保证正确添加了else做一个逻辑保证,其实如果写else,这段代码也不会发生逻辑错误,而且一旦忘记写花括号时候,语法编译器会提示添加,甚至可以使用eslint这种工具强制使用花括号...对于我们这么潇洒自如程序猿来说,这种限制实在太麻烦了,用if的话,别说是常量了,函数都可以,真正做到方便快捷。...在早起电脑代码中没有子函数概念,那时候都是用goto随意跳转,你想去第10行代码,很简单goto 10就可以了。...这种编程思维在C早期阶段还是一直受到影响,因此早期C也没有子函数,都是一堆逻辑处理混乱在一起,goto满天飞,所以那时候你没有一个最强大脑写不了程序

    44330

    为什么程序员都不喜欢使用switch,而是大量 if……else if ?

    语法正确逻辑错误 这就是第一个理由为什么程序猿很少使用switch来做条件判断,对于新手来说忘记写break实在再普通不过了,就算是老猿忘记写也是时有发生事情,而这个语法错误在诸多语法检查器上没有办法检查出来...上面的代码为了保证正确添加了else做一个逻辑保证,其实如果写else,这段代码也不会发生逻辑错误,而且一旦忘记写花括号时候,语法编译器会提示添加,甚至可以使用eslint这种工具强制使用花括号...对于我们这么潇洒自如程序猿来说,这种限制实在太麻烦了,用if的话,别说是常量了,函数都可以,真正做到方便快捷。...在早起电脑代码中没有子函数概念,那时候都是用goto随意跳转,你想去第10行代码,很简单goto 10就可以了。...这种编程思维在C早期阶段还是一直受到影响,因此早期C也没有子函数,都是一堆逻辑处理混乱在一起,goto满天飞,所以那时候你没有一个最强大脑写不了程序

    54020

    为什么程序员都不喜欢使用switch,而是大量 if…else ?

    语法正确逻辑错误 这就是第一个理由为什么程序猿很少使用switch来做条件判断,对于新手来说忘记写break实在再普通不过了,就算是老猿忘记写也是时有发生事情,而这个语法错误在诸多语法检查器上没有办法检查出来...上面的代码为了保证正确添加了else做一个逻辑保证,其实如果写else,这段代码也不会发生逻辑错误,而且一旦忘记写花括号时候,语法编译器会提示添加,甚至可以使用eslint这种工具强制使用花括号...对于我们这么潇洒自如程序猿来说,这种限制实在太麻烦了,用if的话,别说是常量了,函数都可以,真正做到方便快捷。...在早起电脑代码中没有子函数概念,那时候都是用goto随意跳转,你想去第10行代码,很简单goto 10就可以了。...这种编程思维在C早期阶段还是一直受到影响,因此早期C也没有子函数,都是一堆逻辑处理混乱在一起,goto满天飞,所以那时候你没有一个最强大脑写不了程序

    55220

    为什么程序员都不喜欢使用switch,而是大量 if……else if ?

    语法正确逻辑错误 这就是第一个理由为什么程序猿很少使用switch来做条件判断,对于新手来说忘记写break实在再普通不过了,就算是老猿忘记写也是时有发生事情,而这个语法错误在诸多语法检查器上没有办法检查出来...上面的代码为了保证正确添加了else做一个逻辑保证,其实如果写else,这段代码也不会发生逻辑错误,而且一旦忘记写花括号时候,语法编译器会提示添加,甚至可以使用eslint这种工具强制使用花括号...对于我们这么潇洒自如程序猿来说,这种限制实在太麻烦了,用if的话,别说是常量了,函数都可以,真正做到方便快捷。...在早起电脑代码中没有子函数概念,那时候都是用goto随意跳转,你想去第10行代码,很简单goto 10就可以了。...这种编程思维在C早期阶段还是一直受到影响,因此早期C也没有子函数,都是一堆逻辑处理混乱在一起,goto满天飞,所以那时候你没有一个最强大脑写不了程序

    37910

    为什么程序员都不喜欢使用switch,而是大量 if……else if ?

    语法正确逻辑错误 这就是第一个理由为什么程序猿很少使用switch来做条件判断,对于新手来说忘记写break实在再普通不过了,就算是老猿忘记写也是时有发生事情,而这个语法错误在诸多语法检查器上没有办法检查出来...上面的代码为了保证正确添加了else做一个逻辑保证,其实如果写else,这段代码也不会发生逻辑错误,而且一旦忘记写花括号时候,语法编译器会提示添加,甚至可以使用eslint这种工具强制使用花括号...对于我们这么潇洒自如程序猿来说,这种限制实在太麻烦了,用if的话,别说是常量了,函数都可以,真正做到方便快捷。...在早起电脑代码中没有子函数概念,那时候都是用goto随意跳转,你想去第10行代码,很简单goto 10就可以了。...这种编程思维在C早期阶段还是一直受到影响,因此早期C也没有子函数,都是一堆逻辑处理混乱在一起,goto满天飞,所以那时候你没有一个最强大脑写不了程序

    1.1K20

    编程智慧

    只有40行而不是50行原因眼球转的话,最大视角只看得到40行代码。 如果看代码转眼球的话,就能把整片代码完整映射到我视觉神经里,这样就算忽然闭上眼睛,也能看得见这段代码。...这就是为什么command1成功,才会执行command2,command2成功,才会执行command3。...这种写法缺点x<5不成立时候,你需要往上面看,才能知道s值是什么。这还是你运气好时候,因为s就在上面不远。...你代码逻辑基于判断A是否出现,可你却catch所有的异常(Exception类),所以其它异常B出现时候,你代码就会出现莫名其妙问题,因为你以为A出现了,而其实它没有。...那里面少数几个东西表达能力,论工作原理,却可以扯到functor,continuation,甚至monad等高深理论…… 仿佛用了Optional之后,这语言就不再Java了一样。

    42610

    Kotlin 协程总结

    a.什么时候需要自定义 suspend 函数 a.具体该怎么写 5.小结 三、挂起非阻塞式怎么回事 1.什么「非阻塞式挂起」 2.为什么要讲非阻塞式挂起 3.协程与线程 4.小结 四、总结 一、协程是什么...这里api.getUser一个挂起函数,所以能够保证nameTv.text正确赋值,这就涉及到了协程中最著名「非阻塞式挂起」。这个名词看起来不是那么容易理解,后面会讲。...suspend 有暂停意思,但我们在协程中应该理解为:线程执行到协程 suspend 函数时候,暂时继续执行协程代码了。...函数创建者对函数使用者提醒:一个耗时函数被我创建者用挂起方式放在后台运行,所以请在协程里调用。...2.为什么要讲非阻塞式挂起 协程只是在写法上「看起来阻塞」,其实是「非阻塞」,因为在协程里面它做了很多工作,其中有一个就是帮我们切线程。

    3.2K11

    通俗易懂 | SVMHingeLoss

    这里,如果SVM一个线性,那么SVM模型其实就是一个线性分类器: 基本就这么多了,咱们开始看损失函数吧。 在学这个之前,如果你已经学过了逻辑回归,那就更好了。...对于SVM来说: 时候,至少要大于0吧,也许越大越好; 时候,至少要小于0吧,也许越小越好; 【为什么用“也许”呢?如果?】时候,和哪个更好,其实我们并不能得到正确答案。...然后上面的平方损失,就是途中红色曲线。我们先品一品是什么? 大于0时候,其实就是和同符号,也就是预测正确了。 越大时候,也就是模型预测也稳。比较抽象哈。...你考80分怎么还比70分得到更大损失。 【这也是分类问题为什么不使用平方损失原因。因为回归时候,要预测一个数值,高了低了都不好。...看一下交叉熵SVM损失函数: ? 这个绿色损失看起来不错,比平方损失强多了。 ---- 目前:交叉熵完爆平方损失。

    1.7K30

    深度思考编程艺术

    编程一种创造性工作一门艺术。精通任何一门艺术,都需要很多练习和领悟,所以这里提出“智慧”,并不是号称一天瘦十斤减肥药,它并不能代替你自己勤奋。...过几个星期或者几个月再回头来看,也许就有焕然一新灵感。这样反反复复很多次之后,你就积累起了灵感和智慧,从而能够在遇到新问题时候直接朝正确,或者接近正确方向前进。...但是如果你在抽屉里再放几个小盒子,把物品分门别类放进去,那么它们就不会到处乱跑,你就可以比较容易找到和管理它们。 优雅代码另一个特征,它逻辑大体上看起来枝丫分明树状结构(tree)。...只有40行而不是50行原因眼球转的话,最大视角只看得到40行代码。 如果看代码转眼球的话,就能把整片代码完整映射到我视觉神经里,这样就算忽然闭上眼睛,也能看得见这段代码。...循环语句(for,while)里面出现return没问题,然而如果你使用了continue或者break,就会让循环逻辑和终止条件变得复杂,难以确保正确

    49880

    React Ref 为什么对象

    const ref = useRef(null); // 声明 refconsole.log(ref.current); // 使用 ref 为什么直接设计成 console.log(ref)先说结论...),useDownload hook 唯一依赖于 DOM 节点,因此很自然地将 DOM 节点即 reviewRef.current 当做函数参数传入 useDownload hook 中/*** 下载预览区域为图片业务逻辑钩子...❓按照 React 运作时序来分析,函数组件 App 最后一段 return 代码执行完后, ref.current 值从 null 被更新为 DOM 元素对象引用,代码执行完毕,函数作用域被回收...,变化传给自定义hook 参数,参数变成了完整 reviewRef 对象,而非精摘出来 reviewRef.current 值, onClick 回调被执行时,onClick 函数作用域在 App...以此延伸到在一些别的场景下我们也可以通过将函数形参传递成object形式以规避维护数据一致性额外工作

    1.5K20

    上下文变量值(context values)陷阱及在 Go 中如何避免或缓和这些陷阱

    上面两个例子很接近认为正确使用上下文变量值场景,但是关键他们都只存活于请求生命周期之内。...这个上下文变量看起来毫无必要"。 从技术角度来说,这是正确。我们可以直接调用,如果你正在写一个相对简单应用也建议你直接调用,但是如果逻辑突然变得更复杂了或者我们应用规模增大了的话会怎样呢?...这看起来并不糟糕,但是如果我们想要在处理器中进行四或五种不同中间处理时候会怎样呢?就像生成一个唯一请求 ID,创建一个日志接收器利用这个请求 ID,验证用户是否登陆,验证用户是否管理员?...函数需要数据被隐藏了 使用上下文变量时候最大关切难以确定函数需要处理数据。...代码复制-需要时再查抄数据 我们简要讨论了什么时候为什么开发者会使用上下文变量,但是想在这里也谈谈之前没谈内容。

    1.6K30

    分享 10 个前端开发者需要知道 JS 技巧

    经常只写成功请求代码逻辑,而忽略请求失败。...给一个函数设置太多参数 一个函数参数太多时,它可读性就会降低,甚至,让我们想知道如何正确传递参数。 例子 我们想要获取用户一些基本信息,比如姓名、性别、年龄等。...那太糟了,如果你同事这样写代码,你会揍他吗? 事实上,函数参数过多时,应该使用对象来传递需要信息,这样它可读性和可扩展性都会得到提高。...✅ const maxWidth = 375 9.不要删除推荐使用代码 很多时候,我们网站会不断调整功能,有新和弃用功能,但我总是担心以后会用到,所以我只是评论它们,而不是删除它们。...写在最后 这些都是工作一些经验总结,希望这篇文章内容对你有所帮助,最后,谢谢您阅读,同时,也期待您关注,点赞,以及阅读更多其他文章。

    43540

    这么学习nginx 499

    说说通过这个499问题一步一步分析整个过程,不一定正确,但很有意思。 故事背景 前几天同组应届生同事在排查线上问题时候突然问我,这个499错误码是什么?...RST怎么产生,整理这篇文章时候已经不记得当初为什么又这个疑问了,这里假设我们还是对这个问题很好奇,不然接下来文字好像没法继续写了。...socket)关闭了读取通道(RCV_SHUTDOWN) 函数收到数据包有内容且检测seq序列号正确(可能某个很早包在网络世界中漫游到现在才收到,这种情况要走其他逻辑处理) 看来事情已经很简单了...执行close函数socket引用计数位0时候,会真正去断开连接,这个系统调用背后执行了 tcp_close 函数。...切换到linux项目,搜索ENOTCONN(看起来当前场景错误码),结果让人大失所望。 ?

    2K21
    领券